diff --git a/docs/drivers/freedreno/isaspec.rst b/docs/drivers/freedreno/isaspec.rst index ef2c030c5c8..917ef3d8b10 100644 --- a/docs/drivers/freedreno/isaspec.rst +++ b/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": - 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. @@ -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 ```` 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 ```` 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, ````, ````, and ```` 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 ```` elements teach the encoder how to map from the encode diff --git a/docs/gallium/screen.rst b/docs/gallium/screen.rst index e347ebe0258..9890af9bce2 100644 --- a/docs/gallium/screen.rst +++ b/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 diff --git a/docs/rusticl.rst b/docs/rusticl.rst index 3a65390b6ff..45f99bcca3c 100644 --- a/docs/rusticl.rst +++ b/docs/rusticl.rst @@ -12,7 +12,7 @@ To build Rusticl you need to satisfy the following build dependencies: - `SPIRV-Tools `__ - `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``.