docs: remove needless c:expr roles

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

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
+`RGB565` format, each :c:type:`vec3` takes up 16 bits and the
-:c:expr:`i`'th color value is accessed as:
+`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
+component sizes such as `RGBA1010102` or where the components are
-smaller than 8 bits such as :c:expr:`RGB565` discussed above.  It does,
+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
+implied directly from the format name with `RGBA8888` storing the
-formats as in the first example and :c:expr:`BGRA8888` storing them in the BGRA
+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
+formats where the entire color fits in `n` bits and formats without the
-:c:expr:`_PACKEDn` suffix are array formats.  In GL, if you specify one of 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.

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
+suffix that declares the units for that particular value: "`_el`" for elements,
-elements, ":c:expr:`_sa`" for samples, etc.  If the units of the particular
+"`_sa`" for samples, etc.  If the units of the particular field aren't quite
-field aren't quite what is wanted by the hardware, we do the conversion when we
+what is wanted by the hardware, we do the conversion when we emit
-emit :c:expr:`RENDER_SURFACE_STATE`.
+`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

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.