diff options
Diffstat (limited to 'docs')
-rw-r--r-- | docs/isl/formats.rst | 18 | ||||
-rw-r--r-- | docs/isl/units.rst | 10 | ||||
-rw-r--r-- | docs/nir/alu.rst | 2 |
3 files changed, 15 insertions, 15 deletions
diff --git a/docs/isl/formats.rst b/docs/isl/formats.rst index c70fcdf5d49..da8f5cc98a8 100644 --- a/docs/isl/formats.rst +++ b/docs/isl/formats.rst @@ -30,7 +30,7 @@ The different data layouts fall into two categories: array and packed. When an array layout is used, the components are stored sequentially in an array of the given encoding. For instance, if the data is encoded in an 8-bit RGBA array format the data is stored in an array of type :c:type:`uint8_t` where the blue -component of the :c:expr:`i`'th color value is accessed as: +component of the `i`'th color value is accessed as: .. code-block:: C @@ -46,8 +46,8 @@ a standard C data type. Packed formats, on the other hand, are encoded with the entire color value packed into a single 8, 16, or 32-bit value. The components are specified by which bits they occupy within that value. For instance, with the popular -:c:expr:`RGB565` format, each :c:type:`vec3` takes up 16 bits and the -:c:expr:`i`'th color value is accessed as: +`RGB565` format, each :c:type:`vec3` takes up 16 bits and the +`i`'th color value is accessed as: .. code-block:: C @@ -56,15 +56,15 @@ which bits they occupy within that value. For instance, with the popular uint8_t b = (*(uint16_t *)data >> 11) & 0x1f; Packed formats are useful because they allow you to specify formats with uneven -component sizes such as :c:expr:`RGBA1010102` or where the components are -smaller than 8 bits such as :c:expr:`RGB565` discussed above. It does, +component sizes such as `RGBA1010102` or where the components are +smaller than 8 bits such as `RGB565` discussed above. It does, however, come with the restriction that the entire vector must fit within 8, 16, or 32 bits. One has to be careful when reasoning about packed formats because it is easy to get the color order wrong. With array formats, the channel ordering is usually -implied directly from the format name with :c:expr:`RGBA8888` storing the -formats as in the first example and :c:expr:`BGRA8888` storing them in the BGRA +implied directly from the format name with `RGBA8888` storing the +formats as in the first example and `BGRA8888` storing them in the BGRA ordering. Packed formats, however, are not as simple because some specifications choose to use a MSB to LSB ordering and others LSB to MSB. One must be careful to pay attention to the enum in question in order to avoid @@ -72,8 +72,8 @@ getting them backwards. From an API perspective, both types of formats are available. In Vulkan, the formats that are of the form :c:enumerator:`VK_FORMAT_xxx_PACKEDn` are packed -formats where the entire color fits in :c:expr:`n` bits and formats without the -:c:expr:`_PACKEDn` suffix are array formats. In GL, if you specify one of the +formats where the entire color fits in `n` bits and formats without the +`_PACKEDn` suffix are array formats. In GL, if you specify one of the base types such as :c:enumerator:`GL_FLOAT` you get an array format but if you specify a packed type such as :c:enumerator:`GL_UNSIGNED_INT_8_8_8_8_REV` you get a packed format. diff --git a/docs/isl/units.rst b/docs/isl/units.rst index 4ec3045dcb1..8092d207f34 100644 --- a/docs/isl/units.rst +++ b/docs/isl/units.rst @@ -15,17 +15,17 @@ are as follows: These units are fundamental to ISL because they allow us to specify information about a surface in a canonical way that isn't dependent on hardware generation. Each field in an ISL data structure that stores any sort of dimension has a -suffix that declares the units for that particular value: ":c:expr:`_el`" for -elements, ":c:expr:`_sa`" for samples, etc. If the units of the particular -field aren't quite what is wanted by the hardware, we do the conversion when we -emit :c:expr:`RENDER_SURFACE_STATE`. +suffix that declares the units for that particular value: "`_el`" for elements, +"`_sa`" for samples, etc. If the units of the particular field aren't quite +what is wanted by the hardware, we do the conversion when we emit +`RENDER_SURFACE_STATE`. This is one of the primary differences between ISL and the old miptree code and one of the core design principles of ISL. In the old miptree code, we tried to keep everything in the same units as the hardware expects but this lead to unnecessary complications as the hardware evolved. One example of this difference is QPitch which specifies the distance between array slices. On -Broadwell and earlier, QPitch field in :c:expr:`RENDER_SURFACE_STATE` was in +Broadwell and earlier, QPitch field in `RENDER_SURFACE_STATE` was in rows of samples. For block-compressed images, this meant it had to be a multiple of the block height. On Skylake, it changed to always being in rows of elements so you have to divide the pitch in samples by the compression diff --git a/docs/nir/alu.rst b/docs/nir/alu.rst index 3dc1ca28b3f..b7af909ad3e 100644 --- a/docs/nir/alu.rst +++ b/docs/nir/alu.rst @@ -50,7 +50,7 @@ While most instruction types in NIR require vector sizes to perfectly match on inputs and outputs, ALU instruction sources have an additional :cpp:member:`nir_alu_src::swizzle` field which allows them to act on vectors which are not the native vector size of the instruction. This is ideal for -hardware with a native data type of :c:expr:`vec4` but also means that ALU +hardware with a native data type of `vec4` but also means that ALU instructions are often used (and required) for packing/unpacking vectors for use in other instruction types like intrinsics or texture ops. |