mirror of https://gitlab.freedesktop.org/mesa/mesa
docs: remove needless c:expr roles
Reviewed-by: Eric Engestrom <eric@igalia.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19575>
This commit is contained in:
parent
4bc1d3e79c
commit
4be9600ccb
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
Loading…
Reference in New Issue