docs: ie. -> i.e.

Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19139>

docs/drivers/freedreno/isaspec.rst

@@ -13,7 +13,7 @@ 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
-(ie. that the specification cannot result in more than one valid
+(i.e. 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
@@ -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, ie.
+   			Destination register is opposite precision as source, i.e.
    			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), ie. GPR vs CONST vs relative GPR/CONST.  For fields
+cat4 instructions), i.e. 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
@@ -210,7 +210,7 @@ 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 (ie. the default case).
+bitset (i.e. the default case).
 
 Expressions
 -----------
@@ -275,7 +275,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.  Ie. in
+with the specified prefix prepended to uppercase'd leaf node name.  I.e. in
 this case, "add.f" becomes ``OPC_ADD_F``.
 
 Individual ``<map>`` elements teach the encoder how to map from the encode

docs/gallium/screen.rst

@@ -259,8 +259,8 @@ The integer capabilities:
 * ``PIPE_CAP_DEVICE_ID``: The device ID (PCI ID) of the underlying hardware.
   0xFFFFFFFF if not available.
 * ``PIPE_CAP_ACCELERATED``: Whether the renderer is hardware accelerated. 0 means
-  not accelerated (ie. CPU rendering), 1 means accelerated (ie. GPU rendering),
-  -1 means unknown (ie. an API translation driver which doesn't known what kind of
+  not accelerated (i.e. CPU rendering), 1 means accelerated (i.e. GPU rendering),
+  -1 means unknown (i.e. an API translation driver which doesn't known what kind of
   hardware it's running above).
 * ``PIPE_CAP_VIDEO_MEMORY``: The amount of video memory in megabytes.
 * ``PIPE_CAP_UMA``: If the device has a unified memory architecture or on-card

docs/rusticl.rst

@@ -12,7 +12,7 @@ To build Rusticl you need to satisfy the following build dependencies:
 -  `SPIRV-Tools <https://github.com/KhronosGroup/SPIRV-Tools>`__
 -  `SPIRV-LLVM-Translator
    <https://github.com/KhronosGroup/SPIRV-LLVM-Translator>`__ for a
-   ``libLLVMSPIRVLib.so`` matching your version of LLVM, ie. if you're
+   ``libLLVMSPIRVLib.so`` matching your version of LLVM, i.e. if you're
    using LLVM 15 (``libLLVM.so.15``), then you need a
    ``libLLVMSPIRVLib.so.15``.