docs/vulkan: use hawkmoth instead of doxygen

Use the hawkmoth c:auto* directives to incorporate vulkan documentation.

Convert @param style parameter descriptions to rst info field lists.
Add static stubs for generated headers. Fix a lot of references, in
particular the symbols are now in the Sphinx C domain, not C++
domain. Tweak syntax here and there.

Based on the earlier work by Erik Faye-Lund <kusmabite@gmail.com>

Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24507>

docs/vulkan/base-objs.rst

@@ -10,27 +10,27 @@ which form the core of the Vulkan runtime code:
 .. contents::
    :local:
 
-As one might expect, :cpp:struct:`vk_instance` is the required base struct
-for implementing ``VkInstance``, :cpp:struct:`vk_physical_device` is
-required for ``VkPhysicalDevice``, and :cpp:struct:`vk_device` for
+As one might expect, :c:struct:`vk_instance` is the required base struct
+for implementing ``VkInstance``, :c:struct:`vk_physical_device` is
+required for ``VkPhysicalDevice``, and :c:struct:`vk_device` for
 ``VkDevice``.  Everything else must derive from
-:cpp:struct:`vk_object_base` or from some struct that derives from
-:cpp:struct:`vk_object_base`.
+:c:struct:`vk_object_base` or from some struct that derives from
+:c:struct:`vk_object_base`.
 
 
 vk_object_base
 --------------
 
 The root base struct for all Vulkan objects is
-:cpp:struct:`vk_object_base`.  Every object exposed to the client through
-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
+:c:struct:`vk_object_base`.  Every object exposed to the client through
+the Vulkan API *must* inherit from :c:struct:`vk_object_base` by having a
+:c:struct:`vk_object_base` or some struct that inherits from
+:c:struct:`vk_object_base` as the driver struct's first member.  Even
 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
+:c: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
-the same as the address of the :cpp:struct:`vk_object_base`.
+the same as the address of the :c:struct:`vk_object_base`.
 
 The standard pattern for defining a Vulkan object inside a driver looks
 something like this:
@@ -66,40 +66,44 @@ Then, to the object in a Vulkan entrypoint,
       vk_object_free(&device->vk, pAllocator, sampler);
    }
 
-The :cpp:any:`VK_DEFINE_NONDISP_HANDLE_CASTS()` macro defines a set of
+The :c:macro:`VK_DEFINE_NONDISP_HANDLE_CASTS()` macro defines a set of
 type-safe cast functions called ``drv_sampler_from_handle()`` and
-``drv_sampler_to_handle()`` which cast a :cpp:type:`VkSampler` to and from a
+``drv_sampler_to_handle()`` which cast a :c:type:`VkSampler` to and from a
 ``struct drv_sampler *``.  Because compile-time type checking with Vulkan
 handle types doesn't always work in C, the ``_from_handle()`` helper uses the
-provided :cpp:type:`VkObjectType` to assert at runtime that the provided
+provided :c:type:`VkObjectType` to assert at runtime that the provided
 handle is the correct type of object.  Both cast helpers properly handle
-``NULL`` and ``VK_NULL_HANDLE`` as inputs.  The :cpp:any:`VK_FROM_HANDLE()`
+``NULL`` and ``VK_NULL_HANDLE`` as inputs.  The :c:macro:`VK_FROM_HANDLE()`
 macro provides a convenient way to declare a ``drv_foo`` pointer and
 initialize it from a ``VkFoo`` handle in one smooth motion.
 
-.. doxygenstruct:: vk_object_base
+.. c:autostruct:: vk_object_base
+   :file: src/vulkan/runtime/vk_object.h
    :members:
 
-.. doxygenfunction:: vk_object_base_init
-.. doxygenfunction:: vk_object_base_finish
+.. c:autofunction:: vk_object_base_init
 
-.. doxygendefine:: VK_DEFINE_HANDLE_CASTS
+.. c:autofunction:: vk_object_base_finish
 
-.. doxygendefine:: VK_DEFINE_NONDISP_HANDLE_CASTS
+.. c:automacro:: VK_DEFINE_HANDLE_CASTS
 
-.. doxygendefine:: VK_FROM_HANDLE
+.. c:automacro:: VK_DEFINE_NONDISP_HANDLE_CASTS
+
+.. c:automacro:: VK_FROM_HANDLE
 
 
 vk_instance
 -----------
 
-.. doxygenstruct:: vk_instance
+.. c:autostruct:: vk_instance
+   :file: src/vulkan/runtime/vk_instance.h
    :members:
 
-.. doxygenfunction:: vk_instance_init
-.. doxygenfunction:: vk_instance_finish
+.. c:autofunction:: vk_instance_init
 
-Once a driver has a :cpp:struct:`vk_instance`, implementing all the various
+.. c:autofunction:: vk_instance_finish
+
+Once a driver has a :c:struct:`vk_instance`, implementing all the various
 instance-level ``vkGet*ProcAddr()`` entrypoints is trivial:
 
 .. code-block:: c
@@ -142,9 +146,11 @@ actually defined in the Vulkan headers and you need the prototype somewhere
 to get the C compiler to not complain.  These are all implemented by
 wrapping one of the provided ``vk_instance_get*_proc_addr()`` functions.
 
-.. doxygenfunction:: vk_instance_get_proc_addr
-.. doxygenfunction:: vk_instance_get_proc_addr_unchecked
-.. doxygenfunction:: vk_instance_get_physical_device_proc_addr
+.. c:autofunction:: vk_instance_get_proc_addr
+
+.. c:autofunction:: vk_instance_get_proc_addr_unchecked
+
+.. c:autofunction:: vk_instance_get_physical_device_proc_addr
 
 We also provide an implementation of
 ``vkEnumerateInstanceExtensionProperties()`` which can be used similarly:
@@ -163,22 +169,26 @@ We also provide an implementation of
          &instance_extensions, pPropertyCount, pProperties);
    }
 
-.. doxygenfunction:: vk_enumerate_instance_extension_properties
+.. c:autofunction:: vk_enumerate_instance_extension_properties
 
 vk_physical_device
 ------------------
 
-.. doxygenstruct:: vk_physical_device
+.. c:autostruct:: vk_physical_device
+   :file: src/vulkan/runtime/vk_physical_device.h
    :members:
 
-.. doxygenfunction:: vk_physical_device_init
-.. doxygenfunction:: vk_physical_device_finish
+.. c:autofunction:: vk_physical_device_init
+
+.. c:autofunction:: vk_physical_device_finish
 
 vk_device
 ------------------
 
-.. doxygenstruct:: vk_device
+.. c:autostruct:: vk_device
+   :file: src/vulkan/runtime/vk_device.h
    :members:
 
-.. doxygenfunction:: vk_device_init
-.. doxygenfunction:: vk_device_finish
+.. c:autofunction:: vk_device_init
+
+.. c:autofunction:: vk_device_finish

docs/vulkan/command-pools.rst

@@ -4,10 +4,11 @@ Command Pools
 The Vulkan runtime code provides a common ``VkCommandPool`` implementation
 which makes managing the lifetimes of command buffers and recycling their
 internal state easier.  To use the common command pool a driver needs to
-fill out a :cpp:struct:`vk_command_buffer_ops` struct and set the
-``command_buffer_ops`` field of :cpp:struct:`vk_device`.
+fill out a :c:struct:`vk_command_buffer_ops` struct and set the
+``command_buffer_ops`` field of :c:struct:`vk_device`.
 
-.. doxygenstruct:: vk_command_buffer_ops
+.. c:autostruct:: vk_command_buffer_ops
+   :file: src/vulkan/runtime/vk_command_buffer.h
    :members:
 
 By reducing the entirety of command buffer lifetime management to these
@@ -21,7 +22,7 @@ Command Buffer Recycling
 The common command pool provides automatic command buffer recycling as long
 as the driver uses the common ``vkAllocateCommandBuffers()`` and
 ``vkFreeCommandBuffers()`` implementations.  The driver must also provide the
-``reset`` function pointer in :cpp:struct:`vk_command_buffer_ops`.
+``reset`` function pointer in :c:struct:`vk_command_buffer_ops`.
 
 With the common command buffer pool, when the client calls
 ``vkFreeCommandBuffers()``, the command buffers are not immediately freed.
@@ -39,7 +40,7 @@ Custom command pools
 
 If a driver wishes to recycle at a finer granularity than whole command
 buffers, they can do so by providing their own command pool implementation
-which wraps :cpp:struct:`vk_command_pool`.  The common use-case here is if
+which wraps :c:struct:`vk_command_pool`.  The common use-case here is if
 the driver wants to pool command-buffer-internal objects at a finer
 granularity than whole command buffers.  The command pool provides a place
 where things like GPU command buffers or upload buffers can be cached
@@ -53,7 +54,7 @@ entrypoints:
  - ``vkTrimCommandPool()``
 
 All of the other entrypoints will be handled by common code so long as the
-driver's command pool derives from :cpp:struct:`vk_command_pool`.
+driver's command pool derives from :c:struct:`vk_command_pool`.
 
 The driver implementation of the command buffer ``recycle()`` function
 should respect ``VK_COMMAND_BUFFER_RESET_RELEASE_RESOURCES_BIT`` and, when
@@ -64,15 +65,21 @@ come from the common command buffer code when a command buffer is recycled.
 
 The driver's implementation of ``vkTrimCommandPool()`` should free any
 resources that have been cached within the command pool back to the device
-or back to the OS.  It **must** also call :cpp:func:`vk_command_pool_trim`
+or back to the OS.  It **must** also call :c:func:`vk_command_pool_trim`
 to allow the common code to free any recycled command buffers.
 
 Reference
 ---------
 
-.. doxygenstruct:: vk_command_pool
+.. c:autostruct:: vk_command_pool
+   :file: src/vulkan/runtime/vk_command_pool.h
    :members:
 
-.. doxygenfunction:: vk_command_pool_init
-.. doxygenfunction:: vk_command_pool_finish
-.. doxygenfunction:: vk_command_pool_trim
+.. c:autofunction:: vk_command_pool_init
+   :file: src/vulkan/runtime/vk_command_pool.h
+
+.. c:autofunction:: vk_command_pool_finish
+   :file: src/vulkan/runtime/vk_command_pool.h
+
+.. c:autofunction:: vk_command_pool_trim
+   :file: src/vulkan/runtime/vk_command_pool.h

docs/vulkan/dispatch.rst

@@ -273,7 +273,7 @@ which wrap these functions because those have to be exposed as actual
 symbols from the ``.so`` or ``.dll`` as part of the loader interface.  It
 also has to provide its own ``drv_GetInstanceProcAddr()`` because it needs
 to pass the supported instance extension table to
-:cpp:func:`vk_instance_get_proc_addr`.  The runtime will provide
+:c:func:`vk_instance_get_proc_addr`.  The runtime will provide
 ``vk_common_GetDeviceProcAddr()`` implementations.
 
 

docs/vulkan/graphics-state.rst

@@ -11,32 +11,32 @@ Pipeline state
 --------------
 
 All (possibly dynamic) Vulkan graphics pipeline state is encapsulated into
-a single :cpp:struct:`vk_graphics_pipeline_state` structure which contains
+a single :c:struct:`vk_graphics_pipeline_state` structure which contains
 pointers to sub-structures for each of the different state categories.
-Unlike :cpp:type:`VkGraphicsPipelineCreateInfo`, the pointers in
-:cpp:struct:`vk_graphics_pipeline_state` are guaranteed to be either be
+Unlike :c:type:`VkGraphicsPipelineCreateInfo`, the pointers in
+:c:struct:`vk_graphics_pipeline_state` are guaranteed to be either be
 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
+:c: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``
 chains into a single state structure.  Whenever an extension struct is
 missing, a reasonable default value is provided whenever possible.
 
 
-:cpp:func:`vk_graphics_pipeline_state_fill()` automatically handles both
+:c:func:`vk_graphics_pipeline_state_fill()` automatically handles both
 the render pass and dynamic rendering.  For drivers which use
-:cpp:struct:`vk_render_pass`, the :cpp:struct:`vk_render_pass_state`
+:c:struct:`vk_render_pass`, the :c:struct:`vk_render_pass_state`
 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
-:cpp:struct:`vk_render_pass_state` to the `driver_rp` argument of
-:cpp:func:`vk_graphics_pipeline_state_fill()` with the relevant information
+: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,
-:cpp:struct:`vk_render_pass_state` will be populated with the
-the information from the :cpp:struct:`driver_rp`.  If dynamic
+: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`
-:cpp:struct:`driver_rp`, the :cpp:struct:`vk_render_pass_state`
+: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.
 
@@ -52,7 +52,7 @@ like this:
 
    /* Emit stuff using the state in `state` */
 
-The :cpp:struct:`vk_graphics_pipeline_all_state` structure exists to allow
+The :c:struct:`vk_graphics_pipeline_all_state` structure exists to allow
 the state to sit on the stack instead of requiring a heap allocation.  This
 is useful if you intend to use the state right away and don't need to store
 it.  For pipeline libraries, it's likely more useful to use the dynamically
@@ -78,8 +78,8 @@ library pipeline.
       return result;
 
 State from dependent libraries can be merged together using
-:cpp:func:`vk_graphics_pipeline_state_merge`.
-:cpp:func:`vk_graphics_pipeline_state_fill` will then only attempt to
+:c:func:`vk_graphics_pipeline_state_merge`.
+:c:func:`vk_graphics_pipeline_state_fill` will then only attempt to
 populate missing fields.  You can also merge dependent pipeline libraries
 together but store the final state on the stack for immediate consumption:
 
@@ -96,9 +96,11 @@ together but store the final state on the stack for immediate consumption:
    vk_graphics_pipeline_state_fill(&device->vk, &state, pCreateInfo,
                                    NULL, &all, NULL, 0, NULL);
 
-.. doxygenfunction:: vk_graphics_pipeline_state_fill
+.. c:autofunction:: vk_graphics_pipeline_state_fill
+   :file: src/vulkan/runtime/vk_graphics_state.h
 
-.. doxygenfunction:: vk_graphics_pipeline_state_merge
+.. c:autofunction:: vk_graphics_pipeline_state_merge
+   :file: src/vulkan/runtime/vk_graphics_state.h
 
 
 Dynamic state
@@ -106,32 +108,39 @@ Dynamic state
 
 All dynamic states in Vulkan, regardless of which API version or extension
 introduced them, are represented by the
-:cpp:enum:`mesa_vk_dynamic_graphics_state` enum.  This corresponds to the
-:cpp:type:`VkDynamicState` enum in the Vulkan API only it's compact (has no
+:c:enum:`mesa_vk_dynamic_graphics_state` enum.  This corresponds to the
+:c:type:`VkDynamicState` enum in the Vulkan API only it's compact (has no
 holes due to extension namespacing) and a bit better organized.  Each
 enumerant is named with the name of the state group to which the dynamic
 state belongs as well as the name of the dynamic state itself.  The fact
 that it's compact allows us to use to index bitsets.
 
-.. doxygenfunction:: vk_get_dynamic_graphics_states
+.. c:autofunction:: vk_get_dynamic_graphics_states
+   :file: src/vulkan/runtime/vk_graphics_state.h
 
-We also provide a :cpp:struct:`vk_dynamic_graphics_state` structure which
+We also provide a :c:struct:`vk_dynamic_graphics_state` structure which
 contains all the dynamic graphics states, regardless of which API version
 or extension introduced them.  This structure can be populated from a
-:cpp:struct:`vk_graphics_pipeline_state` via
-:cpp:func:`vk_dynamic_graphics_state_init`.
+:c:struct:`vk_graphics_pipeline_state` via
+:c:func:`vk_dynamic_graphics_state_init`.
 
-.. doxygenfunction:: vk_dynamic_graphics_state_init
-.. doxygenfunction:: vk_dynamic_graphics_state_copy
+.. c:autofunction:: vk_dynamic_graphics_state_init
+   :file: src/vulkan/runtime/vk_graphics_state.h
 
-There is also a :cpp:struct:`vk_dynamic_graphics_state` embedded in
-:cpp:struct:`vk_command_buffer`.  Should you choose to use them, we provide
+.. c:autofunction:: vk_dynamic_graphics_state_copy
+   :file: src/vulkan/runtime/vk_graphics_state.h
+
+There is also a :c:struct:`vk_dynamic_graphics_state` embedded in
+:c:struct:`vk_command_buffer`.  Should you choose to use them, we provide
 common implementations for all ``vkCmdSet*()`` functions.  Two additional
 functions are provided for the driver to call in ``CmdBindPipeline()`` and
 ``CmdBindVertexBuffers2()``:
 
-.. doxygenfunction:: vk_cmd_set_dynamic_graphics_state
-.. doxygenfunction:: vk_cmd_set_vertex_binding_strides
+.. c:autofunction:: vk_cmd_set_dynamic_graphics_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
+
+.. c:autofunction:: vk_cmd_set_vertex_binding_strides
+   :file: src/vulkan/runtime/vk_graphics_state.h
 
 To use the dynamic state framework, you will need the following in your
 pipeline structure:
@@ -193,69 +202,93 @@ Any states used by the currently bound pipeline and attachments are always
 valid in ``vk_command_buffer::dynamic_graphics_state`` so you can always
 use a state even if it isn't dirty on this particular draw.
 
-.. doxygenfunction:: vk_dynamic_graphics_state_dirty_all
-.. doxygenfunction:: vk_dynamic_graphics_state_clear_dirty
-.. doxygenfunction:: vk_dynamic_graphics_state_any_dirty
+.. c:autofunction:: vk_dynamic_graphics_state_dirty_all
+   :file: src/vulkan/runtime/vk_graphics_state.h
+
+.. c:autofunction:: vk_dynamic_graphics_state_clear_dirty
+   :file: src/vulkan/runtime/vk_graphics_state.h
+
+.. c:autofunction:: vk_dynamic_graphics_state_any_dirty
+   :file: src/vulkan/runtime/vk_graphics_state.h
 
 
 Depth stencil state optimization
 --------------------------------
 
-.. doxygenfunction:: vk_optimize_depth_stencil_state
+.. c:autofunction:: vk_optimize_depth_stencil_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
 
 
 Reference
 ---------
 
-.. doxygenstruct:: vk_graphics_pipeline_state
+.. c:autostruct:: vk_graphics_pipeline_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_vertex_binding_state
+.. c:autostruct:: vk_vertex_binding_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_vertex_attribute_state
+.. c:autostruct:: vk_vertex_attribute_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_vertex_input_state
+.. c:autostruct:: vk_vertex_input_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_input_assembly_state
+.. c:autostruct:: vk_input_assembly_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_tessellation_state
+.. c:autostruct:: vk_tessellation_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_viewport_state
+.. c:autostruct:: vk_viewport_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_discard_rectangles_state
+.. c:autostruct:: vk_discard_rectangles_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_rasterization_state
+.. c:autostruct:: vk_rasterization_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_fragment_shading_rate_state
+.. c:autostruct:: vk_fragment_shading_rate_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_sample_locations_state
+.. c:autostruct:: vk_sample_locations_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_multisample_state
+.. c:autostruct:: vk_multisample_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_stencil_test_face_state
+.. c:autostruct:: vk_stencil_test_face_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_depth_stencil_state
+.. c:autostruct:: vk_depth_stencil_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_color_blend_state
+.. c:autostruct:: vk_color_blend_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenstruct:: vk_render_pass_state
+.. c:autostruct:: vk_render_pass_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:
 
-.. doxygenenum:: mesa_vk_dynamic_graphics_state
+.. c:autoenum:: mesa_vk_dynamic_graphics_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
 
-.. doxygenstruct:: vk_dynamic_graphics_state
+.. c:autostruct:: vk_dynamic_graphics_state
+   :file: src/vulkan/runtime/vk_graphics_state.h
    :members:

docs/vulkan/renderpass.rst

@@ -14,25 +14,25 @@ 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`
- - :cpp:func:`vkCmdNextSubpass`
- - :cpp:func:`vkCmdEndRenderPass`
+ - :c:func:`vkCreateRenderPass`
+ - :c:func:`vkCmdBeginRenderPass`
+ - :c:func:`vkCmdNextSubpass`
+ - :c:func:`vkCmdEndRenderPass`
 
 
 Common VkRenderPass implementation
 ----------------------------------
 
 The Vulkan runtime code in Mesa provides a common implementation of
-:cpp:type:`VkRenderPass` called :cpp:struct:`vk_render_pass` which drivers
+:c:type:`VkRenderPass` called :c:struct:`vk_render_pass` which drivers
 can optionally use.  Unlike most Vulkan runtime structs, it's not really
 designed to be used as a base for a driver-specific struct.  It does,
 however, contain all the information passed to
-:cpp:func:`vkCreateRenderPass2` so it can be used in a driver so long as
+:c:func:`vkCreateRenderPass2` so it can be used in a driver so long as
 that driver doesn't need to do any additional compilation at
-:cpp:func:`vkCreateRenderPass2` time.  If a driver chooses to use
-:cpp:struct:`vk_render_pass`, the Vulkan runtime provides implementations
-of :cpp:func:`vkCreateRenderPass2` and :cpp:func:`vkDestroyRenderPass`.
+:c:func:`vkCreateRenderPass2` time.  If a driver chooses to use
+:c:struct:`vk_render_pass`, the Vulkan runtime provides implementations
+of :c:func:`vkCreateRenderPass2` and :c:func:`vkDestroyRenderPass`.
 
 
 :ext:`VK_KHR_dynamic_rendering`
@@ -42,40 +42,43 @@ For drivers which don't need to do subpass combining, it is recommended
 that they skip implementing render passes entirely and implement
 :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`:
+:c:func:`vkCmdBeginRendering` and :c:func:`vkCmdEndRendering`:
 
- - :cpp:func:`vkCmdBeginRenderPass2`
- - :cpp:func:`vkCmdNextSubpass2`
- - :cpp:func:`vkCmdEndRenderPass2`
+ - :c:func:`vkCmdBeginRenderPass2`
+ - :c:func:`vkCmdNextSubpass2`
+ - :c:func:`vkCmdEndRenderPass2`
 
 We also provide a no-op implementation of
-:cpp:func:`vkGetRenderAreaGranularity` which returns a render area
+:c:func:`vkGetRenderAreaGranularity` which returns a render area
 granularity of 1x1.
 
 Drivers which wish to use the common render pass implementation in this way
 **must** also support a Mesa-specific pseudo-extension which optionally
 provides an initial image layout for each attachment at
-:cpp:func:`vkCmdBeginRendering` time.  This is required for us to combine
+:c:func:`vkCmdBeginRendering` time.  This is required for us to combine
 render pass clears with layout transitions, often from
-:cpp:enum:`VK_IMAGE_LAYOUT_UNDEFINED`.  On at least Intel and AMD,
+:c:enum:`VK_IMAGE_LAYOUT_UNDEFINED`.  On at least Intel and AMD,
 combining these transitions with clears is important for performance.
 
-.. doxygenstruct:: VkRenderingAttachmentInitialLayoutInfoMESA
+.. c:autostruct:: VkRenderingAttachmentInitialLayoutInfoMESA
+   :file: src/vulkan/runtime/vk_render_pass.h
    :members:
 
 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
+:c:func:`vkCmdCreateGraphicsPipelines` and
+:c: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 :ext:`VK_KHR_dynamic_rendering`:
 
-.. doxygenfunction:: vk_get_pipeline_rendering_create_info
+.. c:autofunction:: vk_get_pipeline_rendering_create_info
+   :file: src/vulkan/runtime/vk_render_pass.h
 
-.. doxygenfunction:: vk_get_command_buffer_inheritance_rendering_info
+.. c:autofunction:: vk_get_command_buffer_inheritance_rendering_info
+   :file: src/vulkan/runtime/vk_render_pass.h
 
 Apart from handling layout transitions, the common render pass
 implementation mostly ignores input attachments.  It is expected that the
-driver call :cpp:func:`nir_lower_input_attachments` to turn them into
+driver call :c: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. ``VK_EXT_attachment_feedback_loop_layout`` provides
@@ -84,20 +87,25 @@ information on when these self dependencies are present.
 vk_render_pass reference
 ------------------------
 
-The following is a reference for the :cpp:struct:`vk_render_pass` structure
+The following is a reference for the :c:struct:`vk_render_pass` structure
 and its substructures.
 
-.. doxygenstruct:: vk_render_pass
+.. c:autostruct:: vk_render_pass
+   :file: src/vulkan/runtime/vk_render_pass.h
    :members:
 
-.. doxygenstruct:: vk_render_pass_attachment
+.. c:autostruct:: vk_render_pass_attachment
+   :file: src/vulkan/runtime/vk_render_pass.h
    :members:
 
-.. doxygenstruct:: vk_subpass
+.. c:autostruct:: vk_subpass
+   :file: src/vulkan/runtime/vk_render_pass.h
    :members:
 
-.. doxygenstruct:: vk_subpass_attachment
+.. c:autostruct:: vk_subpass_attachment
+   :file: src/vulkan/runtime/vk_render_pass.h
    :members:
 
-.. doxygenstruct:: vk_subpass_dependency
+.. c:autostruct:: vk_subpass_dependency
+   :file: src/vulkan/runtime/vk_render_pass.h
    :members: