From 13b88747d4048a1c9a5acd9dcd6ef43965b119ca Mon Sep 17 00:00:00 2001 From: Eric Engestrom Date: Mon, 1 Apr 2024 11:42:51 +0100 Subject: [PATCH] docs: fix inline c identifier reference -> inline code Part-of: --- docs/drivers/freedreno.rst | 8 ++++---- docs/envvars.rst | 2 +- docs/gallium/context.rst | 2 +- docs/gallium/screen.rst | 2 +- docs/isl/formats.rst | 18 +++++++++--------- docs/isl/units.rst | 8 ++++---- docs/macos.rst | 2 +- docs/vulkan/graphics-state.rst | 4 ++-- 8 files changed, 23 insertions(+), 23 deletions(-) diff --git a/docs/drivers/freedreno.rst b/docs/drivers/freedreno.rst index acc13c95821..5b65873a83a 100644 --- a/docs/drivers/freedreno.rst +++ b/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. diff --git a/docs/envvars.rst b/docs/envvars.rst index 7b56a78b9c2..1eac3303954 100644 --- a/docs/envvars.rst +++ b/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 diff --git a/docs/gallium/context.rst b/docs/gallium/context.rst index e30c9594acd..a4c521e0816 100644 --- a/docs/gallium/context.rst +++ b/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``. diff --git a/docs/gallium/screen.rst b/docs/gallium/screen.rst index 8d418316d76..643df436d0c 100644 --- a/docs/gallium/screen.rst +++ b/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 diff --git a/docs/isl/formats.rst b/docs/isl/formats.rst index 9403fa7346b..1597184a276 100644 --- a/docs/isl/formats.rst +++ b/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. diff --git a/docs/isl/units.rst b/docs/isl/units.rst index 1dfe6a1443e..bbc0873d3b0 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: "`_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 diff --git a/docs/macos.rst b/docs/macos.rst index 0a1af4e6f6f..b2f726ad9a2 100644 --- a/docs/macos.rst +++ b/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=`` build option. Do not use with the previous software rasterizers options, instead add `swrast` to the ```` 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=`` build option. Do not use with the previous software rasterizers options, instead add ``swrast`` to the ```` 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. diff --git a/docs/vulkan/graphics-state.rst b/docs/vulkan/graphics-state.rst index 3ab393b4bed..7ce7d92cb09 100644 --- a/docs/vulkan/graphics-state.rst +++ b/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.