Import Mesa 21.1.5

7 files changed, 24 insertions, 30 deletions

diff --git a/lib/mesa/docs/_extra/specs/MESA_multithread_makecurrent.spec b/lib/mesa/docs/_extra/specs/MESA_multithread_makecurrent.spec
index 7a5873138..5065c2fc0 100644
--- a/lib/mesa/docs/_extra/specs/MESA_multithread_makecurrent.spec
+++ b/lib/mesa/docs/_extra/specs/MESA_multithread_makecurrent.spec
@@ -70,7 +70,7 @@ Changes to Chapter 2 of the GLX 1.3 Specification (Functions and Errors)
 	In addition, an indirect rendering context can be current for
 	only one thread at a time.  A direct rendering context may be
 	current to multiple threads, with synchronization of access to
-	the context through the GL managed by the application through
+	the context thruogh the GL managed by the application through
 	mutexes.
 
 Changes to Chapter 3 of the GLX 1.3 Specification (Functions and Errors)
diff --git a/lib/mesa/docs/_extra/specs/MESA_query_renderer.spec b/lib/mesa/docs/_extra/specs/MESA_query_renderer.spec
index f6209ba8f..10f68ecc5 100644
--- a/lib/mesa/docs/_extra/specs/MESA_query_renderer.spec
+++ b/lib/mesa/docs/_extra/specs/MESA_query_renderer.spec
@@ -360,7 +360,7 @@ Revision History
     Version 4, 2013/02/01 - Add issue #12 regarding texture / renderbuffer
                             format queries.
 
-    Version 5, 2013/02/14 - Add issues #13 and #14 regarding simpler queries
+    Version 5, 2013/02/14 - Add issues #13 and #14 regarding simpler queires
                             after the context is created and made current.
                             Add issue #15 regarding the string query.
                             Add issue #16 regarding the value type returned
diff --git a/lib/mesa/docs/_extra/specs/MESA_shader_integer_functions.txt b/lib/mesa/docs/_extra/specs/MESA_shader_integer_functions.txt
index 27f86de8e..9fcc9b4c5 100644
--- a/lib/mesa/docs/_extra/specs/MESA_shader_integer_functions.txt
+++ b/lib/mesa/docs/_extra/specs/MESA_shader_integer_functions.txt
@@ -46,7 +46,7 @@ Overview
 
     GL_ARB_gpu_shader5 extends GLSL in a number of useful ways.  Much of this
     added functionality requires significant hardware support.  There are many
-    aspects, however, that can be easily implemented on any GPU with "real"
+    aspects, however, that can be easily implmented on any GPU with "real"
     integer support (as opposed to simulating integers using floating point
     calculations).
 
diff --git a/lib/mesa/docs/_extra/specs/OLD/EGL_MESA_screen_surface.txt b/lib/mesa/docs/_extra/specs/OLD/EGL_MESA_screen_surface.txt
index b86a405a6..698a24057 100644
--- a/lib/mesa/docs/_extra/specs/OLD/EGL_MESA_screen_surface.txt
+++ b/lib/mesa/docs/_extra/specs/OLD/EGL_MESA_screen_surface.txt
@@ -51,7 +51,7 @@ Overview
     monitor.  The screen surface can be scrolled by changing this origin.
 
     This extension also defines functions for controlling the monitor's
-    display mode (width, height, refresh rate, etc), and specifying which
+    display mode (width, height, refresh rate, etc), and specifing which
     screen surface is to be displayed on a monitor.
 
     The new EGLModeMESA type and related functions are very similar to the
diff --git a/lib/mesa/docs/_extra/specs/OLD/MESA_trace.spec b/lib/mesa/docs/_extra/specs/OLD/MESA_trace.spec
index 95cb2a600..dc4166e6b 100644
--- a/lib/mesa/docs/_extra/specs/OLD/MESA_trace.spec
+++ b/lib/mesa/docs/_extra/specs/OLD/MESA_trace.spec
@@ -64,7 +64,7 @@ Issues
       that enjoys privileged access, or that they do not wish to separate
       the tracing code from their driver code base.
 
-    (2) Should the Trace API explicitly support the notion of "frames?
+    (2) Should the Trace API explicitely support the notion of "frames? 
     This would require hooking into glXSwapBuffers calls as well.
 
       RESOLVED: No. The application can use NewTraceMESA/EndTraceMESA
@@ -93,7 +93,7 @@ Issues
     be considered persistent state?
 
       RESOLVED: No. The implementation is not forced to use this information 
-      on subsequent occurrences of name/pointer, and is free to consider it
+      on subsequent occurences of name/pointer, and is free to consider it 
       transient state.
  
     (5) Should comment commands be prohibited between Begin/End?
@@ -218,7 +218,7 @@ Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions)
     Bitmap and DrawPixels commands.
 
     TRACE_ERRORS_BIT_MESA controls logging of all errors. If this bit is 
-    set, GetError will be executed wherever applicable, and the result will
+    set, GetError will be executed whereever applicable, and the result will 
     be added to the trace as a comment. The error returns are cached and 
     returned to the application on its GetError calls. If the user does not 
     wish the additional GetError calls to be performed, this bit should not
diff --git a/lib/mesa/docs/_extra/specs/enums.txt b/lib/mesa/docs/_extra/specs/enums.txt
index 09211c923..9d45eba34 100644
--- a/lib/mesa/docs/_extra/specs/enums.txt
+++ b/lib/mesa/docs/_extra/specs/enums.txt
@@ -11,6 +11,7 @@ GL blocks allocated to Mesa:
        0x8BB0-0x8BBF
 
 Unused EGL blocks allocated to Mesa:
+       0x31DF
        0x3290-0x329F
 
 GL_MESA_packed_depth_stencil
@@ -100,11 +101,7 @@ EGL_WL_bind_wayland_display
         EGL_TEXTURE_Y_XUXV_WL                   0x31D9
         EGL_WAYLAND_Y_INVERTED_WL               0x31DB
 
-EGL_EXT_platform_xcb
+EGL_MESA_platform_xcb
 
         EGL_PLATFORM_XCB_EXT                    0x31DC
         EGL_PLATFORM_XCB_SCREEN_EXT             0x31DE
-
-EGL_EXT_present_opaque
-
-        EGL_PRESENT_OPAQUE_EXT                  0x31DF
diff --git a/lib/mesa/docs/drivers/freedreno/isaspec.rst b/lib/mesa/docs/drivers/freedreno/isaspec.rst
index b87dfaf0e..5ecd7d9be 100644
--- a/lib/mesa/docs/drivers/freedreno/isaspec.rst
+++ b/lib/mesa/docs/drivers/freedreno/isaspec.rst
@@ -1,8 +1,8 @@
 ISASPEC - XML Based ISA Specification
 =====================================
 
-isaspec provides a mechanism to describe an instruction set in XML, and
-generate a disassembler and assembler.  The intention is
+isaspec provides a mechanism to describe an instruction set in xml, and
+generate a disassembler and assembler (eventually).  The intention is
 to describe the instruction set more formally than hand-coded assembler
 and disassembler, and better decouple the shader compiler from the
 underlying instruction encoding to simplify dealing with instruction
@@ -13,16 +13,16 @@ and disassemblers, include easier detection of new bit combinations that
 were not seen before in previous generations due to more rigorous
 description of bits that are expect to be '0' or '1' or 'x' (dontcare)
 and verification that different encodings don't have conflicting bits
-(i.e. that the specification cannot result in more than one valid
+(ie. that the specification cannot result in more than one valid
 interpretation of any bit pattern).
 
-The isaspec tool and XML schema are intended to be generic (not specific
+The isaspec tool and xml schema are intended to be generic (not specific
 to ir3), although there are currently a couple limitations due to short-
 cuts taken to get things up and running (which are mostly not inherent to
-the XML schema, and should not be too difficult to remove from the py and
+the xml schema, and should not be too difficult to remove from the py and
 decode/disasm utility):
 
-* Maximum "field" size is 64b
+* Maximum "bitset" size is 64b
 * Fixed instruction size
 
 Often times, especially when new functionality is added in later gens
@@ -38,8 +38,8 @@ Bitsets
 -------
 
 The fundamental concept of matching a bit-pattern to an instruction
-decoding/encoding is the concept of a hierarchical tree of bitsets.
-This is intended to match how the HW decodes instructions, where certain
+decoding/encoding is the concept of a hierarchial tree of bitsets.
+This is intended to match how the hw decodes instructions, where certain
 bits describe the instruction (and sub-encoding, and so on), and other
 bits describe various operands to the instruction.
 
@@ -81,7 +81,7 @@ group things into instruction "categories":
    	<field name="UL" pos="45" type="bool" display="(ul)"/>
    	<field name="DST_CONV" pos="46" type="bool">
    		<doc>
-   			Destination register is opposite precision as source, i.e.
+   			Destination register is opposite precision as source, ie.
    			if {FULL} is true then destination is half precision, and
    			visa versa.
    		</doc>
@@ -150,7 +150,7 @@ we don't expect, which may signal a new instruction (sub)encoding).
 
 You'll notice that ``SRC1`` refers back to a different bitset hierarchy
 that describes various different src register encoding (used for cat2 and
-cat4 instructions), i.e. GPR vs CONST vs relative GPR/CONST.  For fields
+cat4 instructions), ie. GPR vs CONST vs relative GPR/CONST.  For fields
 which have bitset types, parameters can be "passed" in via ``<param>``
 elements, which can be referred to by the display template string, and/or
 expressions.  For example, this helps to deal with cases where other fields
@@ -178,15 +178,12 @@ outside of that bitset control the encoding/decoding, such as in the
    	<field name="ABSNEG" low="14" high="15" type="#absneg"/>
    </bitset>
 
-At some level in the bitset inheritance hierarchy, there is expected to be a
+At some level in the bitset inheritance hiearchy, there is expected to be a
 ``<display>`` element specifying a template string used during bitset
 decoding.  The display template consists of references to fields (which may
 be derived fields) specified as ``{FIELDNAME}`` and other characters
 which are just echoed through to the resulting decoded bitset.
 
-It is possible to define a line column alignment value per field to influence
-the visual output. It needs to be specified as ``{FIELDNAME:align=xx}``.
-
 The ``<override>`` element will be described in the next section, but it
 provides for both different decoded instruction syntax/mnemonics (when
 simply providing a different display template string) as well as instruction
@@ -201,16 +198,16 @@ Overrides
 In many cases, a bitset is not convenient for describing the expected
 disasm syntax, and/or interpretation of some range of bits differs based
 on some other field or combination of fields.  These *could* be modeled
-as different derived bitsets, at the expense of a combinatorial explosion
+as different derived bitsets, at the expense of a combinatorical explosion
 of the size of the bitset inheritance tree.  For example, *every* cat2
-(and cat3) instruction has both a ``(nopN)`` interpretation in addition to
+(and cat3) instruction has both a ``(nopN)`` interpretation in addtion to
 the ``(rptN`)`` interpretation.
 
 An ``<override>`` in a bitset allows to redefine the display string, and/or
 field definitions from the default case.  If the override's expr(ession)
 evaluates to non-zero, ``<display>``, ``<field>``, and ``<derived>``
 elements take precedence over what is defined in the toplevel of the
-bitset (i.e. the default case).
+bitset (ie. the default case).
 
 Expressions
 -----------
@@ -275,7 +272,7 @@ The ``type`` attribute specifies that the input to encoding an instruction
 is a ``struct ir3_instruction *``.  In the case of bitset hierarchies with
 multiple possible leaf nodes, a ``case-prefix`` attribute should be supplied
 along with a function that maps the bitset encode source to an enum value
-with the specified prefix prepended to uppercase'd leaf node name.  I.e. in
+with the specified prefix prepended to uppercase'd leaf node name.  Ie. in
 this case, "add.f" becomes ``OPC_ADD_F``.
 
 Individual ``<map>`` elements teach the encoder how to map from the encode