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
<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>
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
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
-----------
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
* ``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
- `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``.