sync code with last improvements from OpenBSD

lib/mesa/docs/vulkan/base-objs.rst

@@ -26,7 +26,7 @@ The root base struct for all Vulkan objects is
 the Vulkan API *must* inherit from :cpp:struct:`vk_object_base` by having a
 :cpp:struct:`vk_object_base` or some struct that inherits from
 :cpp:struct:`vk_object_base` as the driver struct's first member.  Even
-though we have `container_of()` and use it liberally, the
+though we have ``container_of()`` and use it liberally, the
 :cpp:struct:`vk_object_base` should be the first member as there are a few
 places, particularly in the logging framework, where we use void pointers
 to avoid casting and this only works if the address of the driver struct is

lib/mesa/docs/vulkan/dispatch.rst

@@ -41,7 +41,7 @@ to iterate over the table.
 
 These tables are are generated automatically using a bit of python code that
 parses the vk.xml from the `Vulkan-Docs repo
-<https://github.com/KhronosGroup/Vulkan-docs/>`_, enumerates the
+<https://github.com/KhronosGroup/Vulkan-docs/>`__, enumerates the
 extensions, sorts them by instance vs. device and generates the table.
 Generating it from XML means that we never have to manually maintain any of
 these data structures; they get automatically updated when someone imports
@@ -246,7 +246,7 @@ Entrypoint lookup
 
 Implementing ``vkGet*ProcAddr()`` is quite complicated because of the
 Vulkan 1.2 rules around exactly when they have to return ``NULL``.  When a
-client calls `vkGet*ProcAddr()`, we go through a three step process resolve
+client calls ``vkGet*ProcAddr()``, we go through a three step process resolve
 the function pointer:
 
  1. A static (generated at compile time) hash table is used to map the
@@ -256,8 +256,9 @@ the function pointer:
     checks against the enabled core API version and extensions.  We use an
     index into the entrypoint table, not the dispatch table, because the
     rules for when an entrypoint should be exposed are per-entrypoint.  For
-    instance, `vkBindImageMemory2` is available on Vulkan 1.1 and later but
-    `vkBindImageMemory2KHR` is available if VK_KHR_bind_memory2 is enabled.
+    instance, ``vkBindImageMemory2`` is available on Vulkan 1.1 and later but
+    ``vkBindImageMemory2KHR`` is available if :ext:`VK_KHR_bind_memory2` is
+    enabled.
 
  3. A compaction table is used to map from the entrypoint table index to
     the dispatch table index and the function is finally fetched from the

lib/mesa/docs/vulkan/graphics-state.rst

@@ -19,7 +19,7 @@ NULL or point to valid and properly populated memory.
 
 When creating a pipeline, the
 :cpp:func:`vk_graphics_pipeline_state_fill()` function can be used to
-gather all of the state from the core structures as well as various `pNext`
+gather all of the state from the core structures as well as various ``pNext``
 chains into a single state structure.  Whenever an extension struct is
 missing, a reasonable default value is provided whenever possible.
 

lib/mesa/docs/vulkan/renderpass.rst

@@ -5,13 +5,14 @@ The Vulkan runtime code in Mesa provides several helpful utilities to make
 managing render passes easier.
 
 
-VK_KHR_create_renderpass2
--------------------------
+:ext:`VK_KHR_create_renderpass2`
+--------------------------------
 
-It is strongly recommended that drivers implement VK_KHR_create_renderpass2
-directly and not bother implementing the old Vulkan 1.0 entrypoints.  If a
-driver does not implement them, the following will be implemented in common
-code in terms of their VK_KHR_create_renderpass2 counterparts:
+It is strongly recommended that drivers implement
+:ext:`VK_KHR_create_renderpass2` directly and not bother implementing the
+old Vulkan 1.0 entrypoints.  If a driver does not implement them, the
+following will be implemented in common code in terms of their
+:ext:`VK_KHR_create_renderpass2` counterparts:
 
  - :cpp:func:`vkCreateRenderPass`
  - :cpp:func:`vkCmdBeginRenderPass`
@@ -34,12 +35,12 @@ that driver doesn't need to do any additional compilation at
 of :cpp:func:`vkCreateRenderPass2` and :cpp:func:`vkDestroyRenderPass`.
 
 
-VK_KHR_dynamic_rendering
-------------------------
+:ext:`VK_KHR_dynamic_rendering`
+-------------------------------
 
 For drivers which don't need to do subpass combining, it is recommended
 that they skip implementing render passes entirely and implement
-VK_KHR_dynamic_rendering instead.  If they choose to do so, the runtime
+:ext:`VK_KHR_dynamic_rendering` instead.  If they choose to do so, the runtime
 will provide the following, implemented in terms of
 :cpp:func:`vkCmdBeginRendering` and :cpp:func:`vkCmdEndRendering`:
 
@@ -66,7 +67,7 @@ Because render passes and subpass indices are also passed into
 :cpp:func:`vkCmdCreateGraphicsPipelines` and
 :cpp:func:`vkCmdExecuteCommands` which we can't implement on the driver's
 behalf, we provide a couple of helpers for getting the render pass
-information in terms of the relevant VK_KHR_dynamic_rendering:
+information in terms of the relevant :ext:`VK_KHR_dynamic_rendering`:
 
 .. doxygenfunction:: vk_get_pipeline_rendering_create_info
 
@@ -77,11 +78,8 @@ implementation mostly ignores input attachments.  It is expected that the
 driver call :cpp:func:`nir_lower_input_attachments` to turn them into
 texturing operations.  The driver **must** support texturing from an input
 attachment at the same time as rendering to it in order to support Vulkan
-subpass self-dependencies.  To assist drivers, we provide self-dependency
-information through another Mesa-specific pseudo-extension:
-
-.. doxygenstruct:: VkRenderingSelfDependencyInfoMESA
-   :members:
+subpass self-dependencies. ``VK_EXT_attachment_feedback_loop_layout`` provides
+information on when these self dependencies are present.
 
 vk_render_pass reference
 ------------------------