OpenHarmony/third_party_mesa3d
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: use ext-role for GL / VK extensions

Browse Source 
This makes sure that we generate proper links to all of these
extensions.

Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19594>
This commit is contained in:
Erik Faye-Lund
2022-11-08 12:05:36 +01:00
committed by Marge Bot
parent f69560bdcb
commit ba78af66c6
20 changed files with 171 additions and 187 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/vulkan/dispatch.rst
View File

@@ -257,7 +257,8 @@ the function pointer:
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.
``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

21
docs/vulkan/renderpass.rst
View File

@@ -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