docs: fix inline c identifier reference -> inline code

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28499>

docs/drivers/freedreno.rst

@@ -431,7 +431,7 @@ The format of hangrd is the same as in ordinary command stream capture.
 Replaying Command Stream
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-`replay` tool allows capturing and replaying ``rd`` to reproduce GPU faults.
+``replay`` tool allows capturing and replaying ``rd`` to reproduce GPU faults.
 Especially useful for transient GPU issues since it has much higher chances to
 reproduce them.
 
@@ -440,7 +440,7 @@ Dumping rendering results or even just memory is currently unsupported.
 - Replaying command streams requires kernel with ``MSM_INFO_SET_IOVA`` support.
 - Requires ``rd`` capture to have full snapshots of the memory (``rd_full`` is enabled).
 
-Replaying is done via `replay` tool:
+Replaying is done via ``replay`` tool:
 
 .. code-block:: sh
 
@@ -629,9 +629,9 @@ the cases where stale data is read.
   ``renderpass``
     stomp registers before each renderpass.
   ``inverse``
-    changes `TU_DEBUG_STALE_REGS_RANGE` meaning to
+    changes ``TU_DEBUG_STALE_REGS_RANGE`` meaning to
     "regs that should NOT be stomped".
 
 The best way to pinpoint the reg which causes a failure is to bisect the regs
 range. In case when a fail is caused by combination of several registers
-the `inverse` flag may be set to find the reg which prevents the failure.
+the ``inverse`` flag may be set to find the reg which prevents the failure.

docs/envvars.rst

@@ -1787,7 +1787,7 @@ PowerVR driver environment variables
 
 .. envvar:: PVR_DEBUG
 
-   A comma-separated list of debug options. Use `PVR_DEBUG=help` to
+   A comma-separated list of debug options. Use ``PVR_DEBUG=help`` to
    print a list of available options.
 
 .. envvar:: ROGUE_DEBUG

docs/gallium/context.rst

@@ -893,7 +893,7 @@ This function allows frontends to query kernel information defined inside
 get_compute_state_subgroup_size
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-This function returns the choosen subgroup size when `launch_grid` is
+This function returns the choosen subgroup size when ``launch_grid`` is
 called with the given block size. This doesn't need to be implemented when
 only one size is reported through ``PIPE_COMPUTE_CAP_SUBGROUP_SIZES`` or
 ``pipe_compute_state_object_info::simd_sizes``.

docs/gallium/screen.rst

@@ -805,7 +805,7 @@ pipe_screen::get_compute_param.
   non-zero means yes, zero means no. Value type: ``uint32_t``
 * ``PIPE_COMPUTE_CAP_SUBGROUP_SIZES``: Ored power of two sizes of a basic execution
   unit in threads. Also known as wavefront size, warp size or SIMD width.
-  E.g. `64 | 32`.
+  E.g. ``64 | 32``.
 * ``PIPE_COMPUTE_CAP_ADDRESS_BITS``: The default compute device address space
   size specified as an unsigned integer value in bits.
 * ``PIPE_COMPUTE_CAP_MAX_VARIABLE_THREADS_PER_BLOCK``: Maximum variable number

docs/isl/formats.rst

@@ -32,7 +32,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 `i`'th color value is accessed as:
+component of the ``i``'th color value is accessed as:
 
 .. code-block:: C
 
@@ -48,8 +48,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
-`RGB565` format, each :c:type:`vec3` takes up 16 bits and the
-`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
 
@@ -58,15 +58,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 `RGBA1010102` or where the components are
-smaller than 8 bits such as `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 `RGBA8888` storing the
-formats as in the first example and `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
@@ -74,8 +74,8 @@ getting them backwards.
 
 From an API perspective, both types of formats are available.  In Vulkan, the
 formats that are of the form ``VK_FORMAT_xxx_PACKEDn`` are packed
-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
+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.

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: "`_el`" for elements,
-"`_sa`" for samples, etc.  If the units of the particular field aren't quite
+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`.
+``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 `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/macos.rst

@@ -18,4 +18,4 @@ to X11 applications on macOS running via XQuartz.
 Mesa's software rasterizers also work on macOS. To build, set the build options
 ``-Dosmesa=true -Dglx=xlib``.
 
-Mesa's Gallium drivers can be used on macOS by using the ``-Dgallium-drivers=<drivers>`` build option. Do not use with the previous software rasterizers options, instead add `swrast` to the ``<drivers>`` list. Only software renderers and drivers that forward to other APIs can work, any linux hardware drivers will not work. For details on each driver's macOS support see their specific documentation.
+Mesa's Gallium drivers can be used on macOS by using the ``-Dgallium-drivers=<drivers>`` build option. Do not use with the previous software rasterizers options, instead add ``swrast`` to the ``<drivers>`` list. Only software renderers and drivers that forward to other APIs can work, any linux hardware drivers will not work. For details on each driver's macOS support see their specific documentation.

docs/vulkan/graphics-state.rst

@@ -30,12 +30,12 @@ the render pass and dynamic rendering.  For drivers which use
 structure will be populated as if for dynamic rendering, regardless of
 which path is used.  Drivers which use their own render pass structure
 should parse the render pass, if available, and pass a
-:c:struct:`vk_render_pass_state` to the `driver_rp` argument of
+:c:struct:`vk_render_pass_state` to the ``driver_rp`` argument of
 :c:func:`vk_graphics_pipeline_state_fill()` with the relevant information
 from the specified subpass.  If a render pass is available,
 :c:struct:`vk_render_pass_state` will be populated with the
 the information from the :c:struct:`driver_rp`.  If dynamic
-rendering is used or the driver provides a `NULL`
+rendering is used or the driver provides a ``NULL``
 :c:struct:`driver_rp`, the :c:struct:`vk_render_pass_state`
 structure will be populated for dynamic rendering, including color, depth,
 and stencil attachment formats.