mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2025-12-29 16:40:13 +01:00
docs: use ext-role for GL / VK extensions
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
Marge Bot
parent
f69560bdcb
commit
ba78af66c6
20 changed files with 171 additions and 187 deletions
|
|
@ -14,7 +14,7 @@ specific to ANV:
|
|||
:envvar:`ANV_DISABLE_SECONDARY_CMD_BUFFER_CALLS`
|
||||
If defined to ``1`` or ``true``, this will prevent usage of self
|
||||
modifying command buffers to implement ``vkCmdExecuteCommands``. As
|
||||
a result of this, it will also disable ``VK_KHR_performance_query``.
|
||||
a result of this, it will also disable :ext:`VK_KHR_performance_query`.
|
||||
:envvar:`ANV_ALWAYS_BINDLESS`
|
||||
If defined to ``1`` or ``true``, this forces all descriptor sets to
|
||||
use the internal `Bindless model`_.
|
||||
|
|
@ -28,7 +28,7 @@ specific to ANV:
|
|||
Haswell, Cherryview).
|
||||
:envvar:`ANV_PRIMITIVE_REPLICATION_MAX_VIEWS`
|
||||
Specifies up to how many view shaders can be lowered to handle
|
||||
VK_KHR_multiview. Beyond this number, multiview is implemented
|
||||
:ext:`VK_KHR_multiview`. Beyond this number, multiview is implemented
|
||||
using instanced rendering. If unspecified, the value default to
|
||||
``2``.
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ Experimental features
|
|||
|
||||
:envvar:`ANV_EXPERIMENTAL_NV_MESH_SHADER`
|
||||
If defined to ``1`` or ``true``, this advertise support for
|
||||
VK_NV_mesh_shader extension for platforms that have hardware
|
||||
:ext:`VK_NV_mesh_shader` extension for platforms that have hardware
|
||||
support for it.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -131,9 +131,9 @@ Here are some known caveats in OpenGL support:
|
|||
that may affect the quality of the texture lookup.
|
||||
|
||||
- Lima supports FP16 textures in OpenGL ES (through
|
||||
``GL_OES_texture_half_float``), but not in OpenGL.
|
||||
This is because it would require ``ARB_texture_float`` which would also
|
||||
require 32-bit float textures, that the Mali-4xx does not support.
|
||||
:ext:`GL_OES_texture_half_float<GL_OES_texture_float>`), but not in OpenGL.
|
||||
This is because it would require :ext:`GL_ARB_texture_float` which would
|
||||
also require 32-bit float textures, that the Mali-4xx does not support.
|
||||
- Rendering to FP16 is possible, but the result is clamped to the
|
||||
[0.0,1.0] range.
|
||||
|
||||
|
|
|
|||
|
|
@ -23,12 +23,12 @@ With the Fall 2018 Workstation 15 / Fusion 11 releases, additional
|
|||
features are supported in the driver:
|
||||
|
||||
- Multisample antialiasing (2x, 4x)
|
||||
- GL_ARB/AMD_draw_buffers_blend
|
||||
- GL_ARB_sample_shading
|
||||
- GL_ARB_texture_cube_map_array
|
||||
- GL_ARB_texture_gather
|
||||
- GL_ARB_texture_query_lod
|
||||
- GL_EXT/OES_draw_buffers_indexed
|
||||
- :ext:`GL_ARB_draw_buffers_blend` / :ext:`GL_AMD_draw_buffers_blend`
|
||||
- :ext:`GL_ARB_sample_shading`
|
||||
- :ext:`GL_ARB_texture_cube_map_array`
|
||||
- :ext:`GL_ARB_texture_gather`
|
||||
- :ext:`GL_ARB_texture_query_lod`
|
||||
- :ext:`GL_EXT_draw_buffers_indexed` / :ext:`GL_OES_draw_buffers_indexed`
|
||||
|
||||
This requires version 2.15.0 or later of the vmwgfx kernel module and
|
||||
the VM must be configured for hardware version 16 or later.
|
||||
|
|
|
|||
|
|
@ -16,9 +16,9 @@ Requirements
|
|||
The Venus renderer requires
|
||||
|
||||
- Vulkan 1.1
|
||||
- ``VK_EXT_external_memory_dma_buf``
|
||||
- ``VK_EXT_image_drm_format_modifier``
|
||||
- ``VK_EXT_queue_family_foreign``
|
||||
- :ext:`VK_EXT_external_memory_dma_buf`
|
||||
- :ext:`VK_EXT_image_drm_format_modifier`
|
||||
- :ext:`VK_EXT_queue_family_foreign`
|
||||
|
||||
from the host driver. However, it violates the spec in some places currently
|
||||
and also relies on implementation-defined behaviors in others. It is not
|
||||
|
|
@ -161,8 +161,8 @@ driver supports the formats, especially multi-planar ones, and the DRM format
|
|||
modifiers of the GBM BOs.
|
||||
|
||||
In the future, if virglrenderer's ``virgl_renderer_export_fence`` is
|
||||
supported, the Venus renderer will require ``VK_KHR_external_fence_fd`` with
|
||||
``VK_EXTERNAL_FENCE_HANDLE_TYPE_SYNC_FD_BIT`` from the host driver.
|
||||
supported, the Venus renderer will require :ext:`VK_KHR_external_fence_fd`
|
||||
with ``VK_EXTERNAL_FENCE_HANDLE_TYPE_SYNC_FD_BIT`` from the host driver.
|
||||
|
||||
VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT
|
||||
-----------------------------------
|
||||
|
|
|
|||
|
|
@ -44,13 +44,13 @@ Here's a list of those requirements:
|
|||
|
||||
* Device extensions:
|
||||
|
||||
* `VK_KHR_maintenance1`_
|
||||
* `VK_KHR_create_renderpass2`_
|
||||
* `VK_KHR_imageless_framebuffer`_
|
||||
* `VK_KHR_timeline_semaphore`_
|
||||
* `VK_EXT_custom_border_color`_ with ``customBorderColorWithoutFormat``
|
||||
* `VK_EXT_provoking_vertex`_
|
||||
* `VK_EXT_line_rasterization`_, with the following ``VkPhysicalDeviceLineRasterizationFeaturesEXT``:
|
||||
* :ext:`VK_KHR_maintenance1`
|
||||
* :ext:`VK_KHR_create_renderpass2`
|
||||
* :ext:`VK_KHR_imageless_framebuffer`
|
||||
* :ext:`VK_KHR_timeline_semaphore`
|
||||
* :ext:`VK_EXT_custom_border_color` with ``customBorderColorWithoutFormat``
|
||||
* :ext:`VK_EXT_provoking_vertex`
|
||||
* :ext:`VK_EXT_line_rasterization`, with the following ``VkPhysicalDeviceLineRasterizationFeaturesEXT``:
|
||||
|
||||
* ``rectangularLines``
|
||||
* ``bresenhamLines``
|
||||
|
|
@ -59,14 +59,14 @@ Here's a list of those requirements:
|
|||
* ``stippledBresenhamLines``
|
||||
* ``stippledSmoothLines``
|
||||
|
||||
* `VK_KHR_swapchain_mutable_format`_
|
||||
* `VK_EXT_border_color_swizzle`_
|
||||
* `VK_KHR_descriptor_update_template`_
|
||||
* :ext:`VK_KHR_swapchain_mutable_format`
|
||||
* :ext:`VK_EXT_border_color_swizzle`
|
||||
* :ext:`VK_KHR_descriptor_update_template`
|
||||
|
||||
In addition to this, `VK_KHR_external_memory`_ is required to support the
|
||||
In addition to this, :ext:`VK_KHR_external_memory` is required to support the
|
||||
DRI code-path.
|
||||
|
||||
We also require either the `VK_EXT_scalar_block_layout`_ extension or
|
||||
We also require either the :ext:`VK_EXT_scalar_block_layout` extension or
|
||||
Vulkan 1.2, with the ``scalarBlockLayout`` feature.
|
||||
|
||||
OpenGL 3.0
|
||||
|
|
@ -82,8 +82,8 @@ supported:
|
|||
|
||||
* Device extensions:
|
||||
|
||||
* `VK_EXT_transform_feedback`_
|
||||
* `VK_EXT_conditional_rendering`_
|
||||
* :ext:`VK_EXT_transform_feedback`
|
||||
* :ext:`VK_EXT_conditional_rendering`
|
||||
|
||||
OpenGL 3.1
|
||||
^^^^^^^^^^
|
||||
|
|
@ -107,7 +107,7 @@ supported, although some of these might not actually get verified:
|
|||
|
||||
* Device extensions:
|
||||
|
||||
* `VK_EXT_depth_clip_enable`_
|
||||
* :ext:`VK_EXT_depth_clip_enable`
|
||||
|
||||
OpenGL 3.3
|
||||
^^^^^^^^^^
|
||||
|
|
@ -121,7 +121,7 @@ supported, although some of these might not actually get verified:
|
|||
|
||||
* Device extensions:
|
||||
|
||||
* `VK_EXT_vertex_attribute_divisor`_
|
||||
* :ext:`VK_EXT_vertex_attribute_divisor`
|
||||
|
||||
OpenGL 4.0
|
||||
^^^^^^^^^^
|
||||
|
|
@ -137,7 +137,7 @@ supported:
|
|||
|
||||
* Device extensions:
|
||||
|
||||
* `VK_KHR_maintenance2`_
|
||||
* :ext:`VK_KHR_maintenance2`
|
||||
|
||||
* Formats requiring ``VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT``:
|
||||
|
||||
|
|
@ -167,7 +167,7 @@ For OpenGL 4.2 support, the following additional requirements must be
|
|||
supported:
|
||||
|
||||
* Device extensions:
|
||||
* `VK_EXT_image_2d_view_of_3d`_
|
||||
* :ext:`VK_EXT_image_2d_view_of_3d`
|
||||
|
||||
* ``VkPhysicalDeviceLimits``:
|
||||
|
||||
|
|
@ -187,7 +187,7 @@ supported:
|
|||
|
||||
* Device extensions:
|
||||
|
||||
* `VK_KHR_shader_draw_parameters`_
|
||||
* :ext:`VK_KHR_shader_draw_parameters`
|
||||
|
||||
OpenGL 4.3
|
||||
^^^^^^^^^^
|
||||
|
|
@ -221,7 +221,7 @@ supported:
|
|||
|
||||
* Device extensions:
|
||||
|
||||
* `VK_KHR_sampler_mirror_clamp_to_edge`_
|
||||
* :ext:`VK_KHR_sampler_mirror_clamp_to_edge`
|
||||
|
||||
OpenGL 4.5
|
||||
^^^^^^^^^^
|
||||
|
|
@ -245,7 +245,7 @@ are required to be supported
|
|||
|
||||
* Device extensions:
|
||||
|
||||
* `VK_KHR_draw_indirect_count`_
|
||||
* :ext:`VK_KHR_draw_indirect_count`
|
||||
|
||||
Performance
|
||||
-----------
|
||||
|
|
@ -308,24 +308,3 @@ questions, don't hesitate to visit `#zink on OFTC
|
|||
|
||||
|
||||
.. _downloaded from GPUinfo.org: https://www.saschawillems.de/blog/2022/03/12/vulkan-profiles-support-for-the-vulkan-hardware-capability-viewer-and-database/>
|
||||
.. _VK_KHR_maintenance1: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_maintenance1.html
|
||||
.. _VK_KHR_create_renderpass2: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_create_renderpass2.html
|
||||
.. _VK_KHR_imageless_framebuffer: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_imageless_framebuffer.html
|
||||
.. _VK_KHR_timeline_semaphore: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_timeline_semaphore.html
|
||||
.. _VK_KHR_external_memory: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_external_memory.html
|
||||
.. _VK_EXT_scalar_block_layout: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_scalar_block_layout.html
|
||||
.. _VK_EXT_transform_feedback: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_transform_feedback.html
|
||||
.. _VK_EXT_conditional_rendering: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_conditional_rendering.html
|
||||
.. _VK_EXT_vertex_attribute_divisor: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_vertex_attribute_divisor.html
|
||||
.. _VK_EXT_image_2d_view_of_3d: https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/VK_EXT_image_2d_view_of_3d.html
|
||||
.. _VK_KHR_maintenance2: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_maintenance2.html
|
||||
.. _VK_KHR_shader_draw_parameters: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_shader_draw_parameters.html
|
||||
.. _VK_KHR_draw_indirect_count: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_draw_indirect_count.html
|
||||
.. _VK_KHR_sampler_mirror_clamp_to_edge: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_sampler_mirror_clamp_to_edge.html
|
||||
.. _VK_EXT_custom_border_color: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_custom_border_color.html
|
||||
.. _VK_EXT_provoking_vertex: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_provoking_vertex.html
|
||||
.. _VK_EXT_line_rasterization: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_line_rasterization.html
|
||||
.. _VK_KHR_swapchain_mutable_format: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_KHR_swapchain_mutable_format.html
|
||||
.. _VK_EXT_border_color_swizzle: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_border_color_swizzle.html
|
||||
.. _VK_EXT_depth_clip_enable: https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/VK_EXT_depth_clip_enable.html
|
||||
.. _VK_KHR_descriptor_update_template: https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/VK_KHR_descriptor_update_template.html
|
||||
|
|
|
|||
|
|
@ -40,8 +40,8 @@ Core Mesa environment variables
|
|||
:envvar:`MESA_NO_SSE`
|
||||
if set, disables Intel SSE optimizations
|
||||
:envvar:`MESA_NO_ERROR`
|
||||
if set to 1, error checking is disabled as per ``KHR_no_error``. This
|
||||
will result in undefined behavior for invalid use of the API, but
|
||||
if set to 1, error checking is disabled as per :ext:`GL_KHR_no_error`.
|
||||
This will result in undefined behavior for invalid use of the API, but
|
||||
can reduce CPU use for apps that are known to be error free.
|
||||
:envvar:`MESA_DEBUG`
|
||||
if set, error messages are printed to stderr. For example, if the
|
||||
|
|
@ -89,11 +89,11 @@ Core Mesa environment variables
|
|||
- ``FC`` is an optional suffix that indicates a forward compatible
|
||||
context. This is only valid for versions >= 3.0.
|
||||
- ``COMPAT`` is an optional suffix that indicates a compatibility
|
||||
context or ``GL_ARB_compatibility`` support. This is only valid
|
||||
context or :ext:`GL_ARB_compatibility` support. This is only valid
|
||||
for versions >= 3.1.
|
||||
- GL versions <= 3.0 are set to a compatibility (non-Core) profile
|
||||
- GL versions = 3.1, depending on the driver, it may or may not have
|
||||
the ``ARB_compatibility`` extension enabled.
|
||||
the :ext:`GL_ARB_compatibility` extension enabled.
|
||||
- GL versions >= 3.2 are set to a Core profile
|
||||
- Examples:
|
||||
|
||||
|
|
@ -104,13 +104,13 @@ Core Mesa environment variables
|
|||
``3.0FC``
|
||||
select a Core+Forward Compatible profile with GL version 3.0.
|
||||
``3.1``
|
||||
select GL version 3.1 with ``GL_ARB_compatibility`` enabled per
|
||||
the driver default.
|
||||
select GL version 3.1 with :ext:`GL_ARB_compatibility` enabled
|
||||
per the driver default.
|
||||
``3.1FC``
|
||||
select GL version 3.1 with forward compatibility and
|
||||
``GL_ARB_compatibility`` disabled.
|
||||
:ext:`GL_ARB_compatibility` disabled.
|
||||
``3.1COMPAT``
|
||||
select GL version 3.1 with ``GL_ARB_compatibility`` enabled.
|
||||
select GL version 3.1 with :ext:`GL_ARB_compatibility` enabled.
|
||||
``X.Y``
|
||||
override GL version to X.Y without changing the profile.
|
||||
``X.YFC``
|
||||
|
|
@ -332,7 +332,7 @@ Intel driver environment variables
|
|||
``perf``
|
||||
emit messages about performance issues
|
||||
``perfmon``
|
||||
emit messages about ``AMD_performance_monitor``
|
||||
emit messages about :ext:`GL_AMD_performance_monitor`
|
||||
``reemit``
|
||||
mark all state dirty on each draw call
|
||||
``rt``
|
||||
|
|
|
|||
|
|
@ -292,8 +292,8 @@ being said, many people have managed to figure out the process.
|
|||
Joining the appropriate mailing lists and asking questions (and
|
||||
searching the archives) is a good way to get information.
|
||||
|
||||
4.3 Why isn't ``GL_EXT_texture_compression_s3tc`` implemented in Mesa?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
4.3 Why isn't :ext:`GL_EXT_texture_compression_s3tc` implemented in Mesa?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Oh but it is! Prior to 2nd October 2017, the Mesa project did not
|
||||
include S3TC support due to intellectual property (IP) and/or patent
|
||||
|
|
|
|||
|
|
@ -182,7 +182,7 @@ Euro Truck Simulator
|
|||
893943 glDrawArrays(mode = GL_TRIANGLES, first = 0, count = 6)
|
||||
|
||||
At the start of this frame, buffer 14 and 15 haven't been used in the previous 2
|
||||
frames, and the ``GL_ARB_sync`` fence has ensured that the GPU has at least started
|
||||
frames, and the :ext:`GL_ARB_sync` fence has ensured that the GPU has at least started
|
||||
frame n-1 as the CPU starts the current frame. The first map is ``offset = 0,
|
||||
INVALIDATE_BUFFER | UNSYNCHRONIZED``, which suggests that the driver should
|
||||
reallocate storage for the mapping even in the ``UNSYNCHRONIZED`` case, except
|
||||
|
|
@ -237,7 +237,7 @@ Plague Inc
|
|||
1640863 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 6, type = GL_UNSIGNED_SHORT, indices = 0x58, basevertex = 4)
|
||||
|
||||
At the start of this frame, the VBOs haven't been used in about 6 frames, and
|
||||
the ``GL_ARB_sync`` fence has ensured that the GPU has started frame n-1.
|
||||
the :ext:`GL_ARB_sync` fence has ensured that the GPU has started frame n-1.
|
||||
|
||||
Note the use of ``glFlushMappedBufferRange()`` on a small fraction of the size
|
||||
of the VBO -- it is important that a blitting driver make use of the flush
|
||||
|
|
@ -299,7 +299,7 @@ Tabletop Simulator
|
|||
1289068 glDrawArrays(mode = GL_TRIANGLE_STRIP, first = 8, count = 4)
|
||||
1289553 glXSwapBuffers(dpy = 0x3e10810, drawable = 23068692)
|
||||
|
||||
In this app, buffer 480 gets used like this every other frame. The ``GL_ARB_sync``
|
||||
In this app, buffer 480 gets used like this every other frame. The :ext:`GL_ARB_sync`
|
||||
fence ensures that frame n-1 has started on the GPU before CPU work starts on
|
||||
the current frame, so the unsynchronized access to the buffers is safe.
|
||||
|
||||
|
|
@ -337,7 +337,7 @@ Hollow Knight
|
|||
1873097 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 36, type = GL_UNSIGNED_SHORT, indices = 0x2d0, basevertex = 240)
|
||||
|
||||
In this app, buffer 29/30 get used like this starting from offset 0 every other
|
||||
frame. The ``GL_ARB_sync`` fence is used to make sure that the GPU has reached the
|
||||
frame. The :ext:`GL_ARB_sync` fence is used to make sure that the GPU has reached the
|
||||
start of the previous frame before we go unsynchronized writing over the n-2
|
||||
frame's buffer.
|
||||
|
||||
|
|
@ -363,7 +363,7 @@ Borderlands 2
|
|||
3563064 glBindBufferARB(target = GL_ELEMENT_ARRAY_BUFFER, buffer = 875)
|
||||
3563065 glDrawElementsInstancedARB(mode = GL_TRIANGLES, count = 72, type = GL_UNSIGNED_SHORT, indices = NULL, instancecount = 28)
|
||||
|
||||
The ``GL_ARB_sync`` fence ensures that the GPU has started frame n-1 before the CPU
|
||||
The :ext:`GL_ARB_sync` fence ensures that the GPU has started frame n-1 before the CPU
|
||||
starts on the current frame.
|
||||
|
||||
This sequence of buffer uploads appears in each frame with the same buffer
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ objects. They all follow simple, one-method binding calls, e.g.
|
|||
PIPE_MAX_VIEWPORTS.
|
||||
* ``set_viewport_states``
|
||||
* ``set_window_rectangles`` sets the window rectangles to be used for
|
||||
rendering, as defined by GL_EXT_window_rectangles. There are two
|
||||
rendering, as defined by :ext:`GL_EXT_window_rectangles`. There are two
|
||||
modes - include and exclude, which define whether the supplied
|
||||
rectangles are to be used for including fragments or excluding
|
||||
them. All of the rectangles are ORed together, so in exclude mode,
|
||||
|
|
@ -122,7 +122,7 @@ objects. They all follow simple, one-method binding calls, e.g.
|
|||
for tessellation.
|
||||
|
||||
* ``set_debug_callback`` sets the callback to be used for reporting
|
||||
various debug messages, eventually reported via KHR_debug and
|
||||
various debug messages, eventually reported via :ext:`GL_KHR_debug` and
|
||||
similar mechanisms.
|
||||
|
||||
Samplers
|
||||
|
|
|
|||
|
|
@ -15,7 +15,8 @@ clamp_vertex_color
|
|||
the execution of the vertex shader, before being passed to the geometry
|
||||
shader or fragment shader.
|
||||
|
||||
OpenGL: glClampColor(GL_CLAMP_VERTEX_COLOR) in GL 3.0 or GL_ARB_color_buffer_float
|
||||
OpenGL: glClampColor(GL_CLAMP_VERTEX_COLOR) in GL 3.0 or
|
||||
:ext:`GL_ARB_color_buffer_float`
|
||||
|
||||
D3D11: seems always disabled
|
||||
|
||||
|
|
@ -28,7 +29,8 @@ clamp_fragment_color
|
|||
Controls whether TGSI_SEMANTIC_COLOR outputs of the fragment shader
|
||||
are clamped to [0, 1].
|
||||
|
||||
OpenGL: glClampColor(GL_CLAMP_FRAGMENT_COLOR) in GL 3.0 or ARB_color_buffer_float
|
||||
OpenGL: glClampColor(GL_CLAMP_FRAGMENT_COLOR) in GL 3.0 or
|
||||
:ext:`GL_ARB_color_buffer_float`
|
||||
|
||||
D3D11: seems always disabled
|
||||
|
||||
|
|
|
|||
|
|
@ -69,11 +69,11 @@ TODO there's no CAP bit currently for this, there's also unspecified size etc. l
|
|||
TODO: is there any chance of supporting GL pixel buffer object acceleration with this?
|
||||
|
||||
|
||||
OpenGL: vertex buffers in GL 1.5 or GL_ARB_vertex_buffer_object
|
||||
OpenGL: vertex buffers in GL 1.5 or :ext:`GL_ARB_vertex_buffer_object`
|
||||
|
||||
- Binding to stream out requires GL 3.0 or GL_NV_transform_feedback
|
||||
- Binding as constant buffers requires GL 3.1 or GL_ARB_uniform_buffer_object
|
||||
- Binding to a sampling stage requires GL 3.1 or GL_ARB_texture_buffer_object
|
||||
- Binding to stream out requires GL 3.0 or :ext:`GL_NV_transform_feedback`
|
||||
- Binding as constant buffers requires GL 3.1 or :ext:`GL_ARB_uniform_buffer_object`
|
||||
- Binding to a sampling stage requires GL 3.1 or :ext:`GL_ARB_texture_buffer_object`
|
||||
|
||||
D3D11: buffer resources
|
||||
- Binding to a render target requires D3D_FEATURE_LEVEL_10_0
|
||||
|
|
@ -93,7 +93,7 @@ PIPE_TEXTURE_1D / PIPE_TEXTURE_1D_ARRAY
|
|||
|
||||
OpenGL: GL_TEXTURE_1D in GL 1.0
|
||||
|
||||
- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or GL_ARB_texture_non_power_of_two
|
||||
- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or :ext:`GL_ARB_texture_non_power_of_two`
|
||||
|
||||
D3D11: 1D textures in D3D_FEATURE_LEVEL_10_0
|
||||
|
||||
|
|
@ -107,7 +107,8 @@ PIPE_TEXTURE_RECT
|
|||
- Must use unnormalized coordinates
|
||||
- Must use a clamp wrap mode
|
||||
|
||||
OpenGL: GL_TEXTURE_RECTANGLE in GL 3.1 or GL_ARB_texture_rectangle or GL_NV_texture_rectangle
|
||||
OpenGL: GL_TEXTURE_RECTANGLE in GL 3.1 or :ext:`GL_ARB_texture_rectangle` or
|
||||
:ext:`GL_NV_texture_rectangle`
|
||||
|
||||
OpenCL: can create OpenCL images based on this, that can then be sampled arbitrarily
|
||||
|
||||
|
|
@ -128,7 +129,7 @@ PIPE_TEXTURE_2D / PIPE_TEXTURE_2D_ARRAY
|
|||
|
||||
OpenGL: GL_TEXTURE_2D in GL 1.0
|
||||
|
||||
- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or GL_ARB_texture_non_power_of_two
|
||||
- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or :ext:`GL_ARB_texture_non_power_of_two`
|
||||
|
||||
OpenCL: can create OpenCL images based on this, that can then be sampled arbitrarily
|
||||
|
||||
|
|
@ -147,9 +148,9 @@ Mipmap dimensions are reduced in all 3 coordinates.
|
|||
- array_size must be 1
|
||||
- Must use normalized coordinates
|
||||
|
||||
OpenGL: GL_TEXTURE_3D in GL 1.2 or GL_EXT_texture3D
|
||||
OpenGL: GL_TEXTURE_3D in GL 1.2 or :ext:`GL_EXT_texture3D`
|
||||
|
||||
- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or GL_ARB_texture_non_power_of_two
|
||||
- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or :ext:`GL_ARB_texture_non_power_of_two`
|
||||
|
||||
D3D11: 3D textures
|
||||
|
||||
|
|
@ -173,11 +174,11 @@ resulting in filtering taking samples from multiple surfaces near to the edge.
|
|||
width and height must be powers of two
|
||||
- Must use normalized coordinates
|
||||
|
||||
OpenGL: GL_TEXTURE_CUBE_MAP in GL 1.3 or EXT_texture_cube_map
|
||||
OpenGL: GL_TEXTURE_CUBE_MAP in GL 1.3 or :ext:`GL_EXT_texture_cube_map`
|
||||
|
||||
- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or GL_ARB_texture_non_power_of_two
|
||||
- Seamless cube maps require GL 3.2 or GL_ARB_seamless_cube_map or GL_AMD_seamless_cubemap_per_texture
|
||||
- Cube map arrays require GL 4.0 or GL_ARB_texture_cube_map_array
|
||||
- PIPE_CAP_NPOT_TEXTURES is equivalent to GL 2.0 or :ext:`GL_ARB_texture_non_power_of_two`
|
||||
- Seamless cube maps require GL 3.2 or :ext:`GL_ARB_seamless_cube_map` or :ext:`GL_AMD_seamless_cubemap_per_texture`
|
||||
- Cube map arrays require GL 4.0 or :ext:`GL_ARB_texture_cube_map_array`
|
||||
|
||||
D3D11: 2D array textures with the D3D11_RESOURCE_MISC_TEXTURECUBE flag
|
||||
|
||||
|
|
@ -191,7 +192,7 @@ Surfaces are views of a resource that can be bound as a framebuffer to serve as
|
|||
|
||||
TODO: write much more on surfaces
|
||||
|
||||
OpenGL: FBOs are collections of surfaces in GL 3.0 or GL_ARB_framebuffer_object
|
||||
OpenGL: FBOs are collections of surfaces in GL 3.0 or :ext:`GL_ARB_framebuffer_object`
|
||||
|
||||
D3D11: render target views and depth/stencil views
|
||||
|
||||
|
|
|
|||
|
|
@ -119,8 +119,9 @@ The integer capabilities:
|
|||
is allowed to return ``0`` in which case ``PIPE_CAP_GLSL_FEATURE_LEVEL`` is
|
||||
used.
|
||||
Note that simply returning the same value as the GLSL feature level cap is
|
||||
incorrect. For example, GLSL version 3.30 does not require ``ARB_gpu_shader5``,
|
||||
but ESSL version 3.20 es does require ``EXT_gpu_shader5``
|
||||
incorrect. For example, GLSL version 3.30 does not require
|
||||
:ext:`GL_EXT_gpu_shader5`, but ESSL version 3.20 es does require
|
||||
:ext:`GL_EXT_gpu_shader5`
|
||||
* ``PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION``: Whether quads adhere to
|
||||
the flatshade_first setting in ``pipe_rasterizer_state``.
|
||||
* ``PIPE_CAP_USER_VERTEX_BUFFERS``: Whether the driver supports user vertex
|
||||
|
|
@ -207,7 +208,7 @@ The integer capabilities:
|
|||
PIPE_ENDIAN_BIG or PIPE_ENDIAN_LITTLE.
|
||||
* ``PIPE_CAP_MIXED_FRAMEBUFFER_SIZES``: Whether it is allowed to have
|
||||
different sizes for fb color/zs attachments. This controls whether
|
||||
ARB_framebuffer_object is provided.
|
||||
:ext:`GL_ARB_framebuffer_object` is provided.
|
||||
* ``PIPE_CAP_VS_LAYER_VIEWPORT``: Whether ``VARYING_SLOT_LAYER`` and
|
||||
``VARYING_SLOT_VIEWPORT`` are supported as vertex shader outputs. Note that
|
||||
the viewport will only be used if multiple viewports are exposed.
|
||||
|
|
@ -270,11 +271,11 @@ The integer capabilities:
|
|||
* ``PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE``: The maximum supported vertex stride.
|
||||
* ``PIPE_CAP_SAMPLER_VIEW_TARGET``: Whether the sampler view's target can be
|
||||
different than the underlying resource's, as permitted by
|
||||
ARB_texture_view. For example a 2d array texture may be reinterpreted as a
|
||||
:ext:`GL_ARB_texture_view`. For example a 2d array texture may be reinterpreted as a
|
||||
cube (array) texture and vice-versa.
|
||||
* ``PIPE_CAP_CLIP_HALFZ``: Whether the driver supports the
|
||||
pipe_rasterizer_state::clip_halfz being set to true. This is required
|
||||
for enabling ARB_clip_control.
|
||||
for enabling :ext:`GL_ARB_clip_control`.
|
||||
* ``PIPE_CAP_POLYGON_OFFSET_CLAMP``: If true, the driver implements support
|
||||
for ``pipe_rasterizer_state::offset_clamp``.
|
||||
* ``PIPE_CAP_MULTISAMPLE_Z_RESOLVE``: Whether the driver supports blitting
|
||||
|
|
@ -303,16 +304,16 @@ The integer capabilities:
|
|||
textures.
|
||||
* ``PIPE_CAP_DEPTH_BOUNDS_TEST``: Whether bounds_test, bounds_min, and
|
||||
bounds_max states of pipe_depth_stencil_alpha_state behave according
|
||||
to the GL_EXT_depth_bounds_test specification.
|
||||
to the :ext:`GL_EXT_depth_bounds_test` specification.
|
||||
* ``PIPE_CAP_TEXTURE_QUERY_SAMPLES``: Whether the ``TXQS`` opcode is supported
|
||||
* ``PIPE_CAP_FORCE_PERSAMPLE_INTERP``: If the driver can force per-sample
|
||||
interpolation for all fragment shader inputs if
|
||||
pipe_rasterizer_state::force_persample_interp is set. This is only used
|
||||
by GL3-level sample shading (ARB_sample_shading). GL4-level sample shading
|
||||
(ARB_gpu_shader5) doesn't use this. While GL3 hardware has a state for it,
|
||||
GL4 hardware will likely need to emulate it with a shader variant, or by
|
||||
selecting the interpolation weights with a conditional assignment
|
||||
in the shader.
|
||||
by GL3-level sample shading (:ext:`GL_ARB_sample_shading`). GL4-level sample
|
||||
shading (:ext:`GL_ARB_gpu_shader5`) doesn't use this. While GL3 hardware has a
|
||||
state for it, GL4 hardware will likely need to emulate it with a shader
|
||||
variant, or by selecting the interpolation weights with a conditional
|
||||
assignment in the shader.
|
||||
* ``PIPE_CAP_SHAREABLE_SHADERS``: Whether shader CSOs can be used by any
|
||||
pipe_context. Important for reducing jank at draw time by letting GL shaders
|
||||
linked in one thread be used in another thread without recompiling.
|
||||
|
|
@ -367,11 +368,13 @@ The integer capabilities:
|
|||
rendering or textures.
|
||||
* ``PIPE_CAP_ROBUST_BUFFER_ACCESS_BEHAVIOR``: Implementation uses bounds
|
||||
checking on resource accesses by shader if the context is created with
|
||||
PIPE_CONTEXT_ROBUST_BUFFER_ACCESS. See the ARB_robust_buffer_access_behavior
|
||||
extension for information on the required behavior for out of bounds accesses
|
||||
and accesses to unbound resources.
|
||||
* ``PIPE_CAP_CULL_DISTANCE``: Whether the driver supports the arb_cull_distance
|
||||
extension and thus implements proper support for culling planes.
|
||||
PIPE_CONTEXT_ROBUST_BUFFER_ACCESS. See the
|
||||
:ext:`GL_ARB_robust_buffer_access_behavior` extension for information on the
|
||||
required behavior for out of bounds accesses and accesses to unbound
|
||||
resources.
|
||||
* ``PIPE_CAP_CULL_DISTANCE``: Whether the driver supports the
|
||||
:ext:`GL_ARB_cull_distance` extension and thus implements proper support for
|
||||
culling planes.
|
||||
* ``PIPE_CAP_CULL_DISTANCE_NOCOMBINE``: Whether the driver wants to skip
|
||||
running the ``nir_lower_clip_cull_distance_arrays`` pass in order to get
|
||||
VARYING_SLOT_CULL_DIST0 slot variables.
|
||||
|
|
@ -401,13 +404,13 @@ The integer capabilities:
|
|||
equal interpolation qualifiers.
|
||||
Components may overlap, notably when the gaps in an array of dvec3 are
|
||||
filled in.
|
||||
* ``PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME``: Whether GL_ARB_transform_feedback2
|
||||
is supported, including pausing/resuming queries and having
|
||||
``count_from_stream_output`` set on indirect draws to implement
|
||||
glDrawTransformFeedback. Required for OpenGL 4.0.
|
||||
* ``PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME``: Whether
|
||||
:ext:`GL_ARB_transform_feedback2` is supported, including pausing/resuming
|
||||
queries and having ``count_from_stream_output`` set on indirect draws to
|
||||
implement glDrawTransformFeedback. Required for OpenGL 4.0.
|
||||
* ``PIPE_CAP_STREAM_OUTPUT_INTERLEAVE_BUFFERS``: Whether interleaved stream
|
||||
output mode is able to interleave across buffers. This is required for
|
||||
ARB_transform_feedback3.
|
||||
:ext:`GL_ARB_transform_feedback3`.
|
||||
* ``PIPE_CAP_SHADER_CAN_READ_OUTPUTS``: Whether every TGSI shader stage can read
|
||||
from the output file.
|
||||
* ``PIPE_CAP_FBFETCH``: The number of render targets whose value in the
|
||||
|
|
@ -459,7 +462,7 @@ The integer capabilities:
|
|||
* ``PIPE_CAP_LOAD_CONSTBUF``: True if the driver supports ``TGSI_OPCODE_LOAD`` use
|
||||
with constant buffers.
|
||||
* ``PIPE_CAP_TILE_RASTER_ORDER``: Whether the driver supports
|
||||
GL_MESA_tile_raster_order, using the tile_raster_order_* fields in
|
||||
:ext:`GL_MESA_tile_raster_order`, using the tile_raster_order_* fields in
|
||||
pipe_rasterizer_state.
|
||||
* ``PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES``: Limit on combined shader
|
||||
output resources (images + buffers + fragment outputs). If 0 the state
|
||||
|
|
@ -509,7 +512,7 @@ The integer capabilities:
|
|||
* ``PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE``: Whether
|
||||
``PIPE_CAP_POST_DEPTH_COVERAGE`` works with conservative rasterization.
|
||||
* ``PIPE_CAP_CONSERVATIVE_RASTER_INNER_COVERAGE``: Whether
|
||||
inner_coverage from GL_INTEL_conservative_rasterization is supported.
|
||||
inner_coverage from :ext:`GL_INTEL_conservative_rasterization` is supported.
|
||||
* ``PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS``: The maximum
|
||||
subpixel precision bias in bits during conservative rasterization.
|
||||
* ``PIPE_CAP_PROGRAMMABLE_SAMPLE_LOCATIONS``: True is the driver supports
|
||||
|
|
@ -534,7 +537,7 @@ The integer capabilities:
|
|||
of pipe_vertex_element::src_offset.
|
||||
* ``PIPE_CAP_SURFACE_SAMPLE_COUNT``: Whether the driver
|
||||
supports pipe_surface overrides of resource nr_samples. If set, will
|
||||
enable EXT_multisampled_render_to_texture.
|
||||
enable :ext:`GL_EXT_multisampled_render_to_texture`.
|
||||
* ``PIPE_CAP_IMAGE_ATOMIC_FLOAT_ADD``: Atomic floating point adds are
|
||||
supported on images, buffers, and shared memory.
|
||||
* ``PIPE_CAP_RGB_OVERRIDE_DST_ALPHA_BLEND``: True if the driver needs blend state to use zero/one instead of destination alpha for RGB/XRGB formats.
|
||||
|
|
@ -577,7 +580,7 @@ The integer capabilities:
|
|||
turn arrays whose contents can be deduced at compile time into constant
|
||||
buffer loads, or false if the driver can handle such arrays itself in a more
|
||||
efficient manner (such as through nir_opt_large_constants() and nir->constant_data).
|
||||
* ``PIPE_CAP_GL_SPIRV``: True if the driver supports ARB_gl_spirv extension.
|
||||
* ``PIPE_CAP_GL_SPIRV``: True if the driver supports :ext:`GL_ARB_gl_spirv` extension.
|
||||
* ``PIPE_CAP_GL_SPIRV_VARIABLE_POINTERS``: True if the driver supports Variable Pointers in SPIR-V shaders.
|
||||
* ``PIPE_CAP_DEMOTE_TO_HELPER_INVOCATION``: True if driver supports demote keyword in GLSL programs.
|
||||
* ``PIPE_CAP_TGSI_TG4_COMPONENT_IN_SWIZZLE``: True if driver wants the TG4 component encoded in sampler swizzle rather than as a separate source.
|
||||
|
|
@ -604,9 +607,9 @@ The integer capabilities:
|
|||
* ``PIPE_CAP_VIEWPORT_TRANSFORM_LOWERED``: Driver needs the nir_lower_viewport_transform pass to be enabled. This also means that the gl_Position value is modified and should be lowered for transform feedback, if needed. Defaults to false.
|
||||
* ``PIPE_CAP_PSIZ_CLAMPED``: Driver needs for the point size to be clamped. Additionally, the gl_PointSize has been modified and its value should be lowered for transform feedback, if needed. Defaults to false.
|
||||
* ``PIPE_CAP_GL_BEGIN_END_BUFFER_SIZE``: Buffer size used to upload vertices for glBegin/glEnd.
|
||||
* ``PIPE_CAP_VIEWPORT_SWIZZLE``: Whether pipe_viewport_state::swizzle can be used to specify pre-clipping swizzling of coordinates (see GL_NV_viewport_swizzle).
|
||||
* ``PIPE_CAP_VIEWPORT_SWIZZLE``: Whether pipe_viewport_state::swizzle can be used to specify pre-clipping swizzling of coordinates (see :ext:`GL_NV_viewport_swizzle`).
|
||||
* ``PIPE_CAP_SYSTEM_SVM``: True if all application memory can be shared with the GPU without explicit mapping.
|
||||
* ``PIPE_CAP_VIEWPORT_MASK``: Whether ``TGSI_SEMANTIC_VIEWPORT_MASK`` and ``TGSI_PROPERTY_LAYER_VIEWPORT_RELATIVE`` are supported (see GL_NV_viewport_array2).
|
||||
* ``PIPE_CAP_VIEWPORT_MASK``: Whether ``TGSI_SEMANTIC_VIEWPORT_MASK`` and ``TGSI_PROPERTY_LAYER_VIEWPORT_RELATIVE`` are supported (see :ext:`GL_NV_viewport_array2`).
|
||||
* ``PIPE_CAP_MAP_UNSYNCHRONIZED_THREAD_SAFE``: Whether mapping a buffer as unsynchronized from any thread is safe.
|
||||
* ``PIPE_CAP_GLSL_ZERO_INIT``: Choose a default zero initialization some GLSL variables. If ``1``, then all GLSL shader variables and gl_FragColor are initialized to zero. If ``2``, then shader out variables are not initialized but function out variables are.
|
||||
* ``PIPE_CAP_BLEND_EQUATION_ADVANCED``: Driver supports blend equation advanced without necessarily supporting FBFETCH.
|
||||
|
|
@ -628,7 +631,7 @@ The integer capabilities:
|
|||
* ``PIPE_CAP_MAX_SPARSE_TEXTURE_SIZE``: Maximum 1D/2D/rectangle texture image dimension for a sparse texture.
|
||||
* ``PIPE_CAP_MAX_SPARSE_3D_TEXTURE_SIZE``: Maximum 3D texture image dimension for a sparse texture.
|
||||
* ``PIPE_CAP_MAX_SPARSE_ARRAY_TEXTURE_LAYERS``: Maximum number of layers in a sparse array texture.
|
||||
* ``PIPE_CAP_SPARSE_TEXTURE_FULL_ARRAY_CUBE_MIPMAPS``: TRUE if there are no restrictions on the allocation of mipmaps in sparse textures and FALSE otherwise. See SPARSE_TEXTURE_FULL_ARRAY_CUBE_MIPMAPS_ARB description in ARB_sparse_texture extension spec.
|
||||
* ``PIPE_CAP_SPARSE_TEXTURE_FULL_ARRAY_CUBE_MIPMAPS``: TRUE if there are no restrictions on the allocation of mipmaps in sparse textures and FALSE otherwise. See SPARSE_TEXTURE_FULL_ARRAY_CUBE_MIPMAPS_ARB description in :ext:`GL_ARB_sparse_texture` extension spec.
|
||||
* ``PIPE_CAP_QUERY_SPARSE_TEXTURE_RESIDENCY``: TRUE if shader sparse texture sample instruction could also return the residency information.
|
||||
* ``PIPE_CAP_CLAMP_SPARSE_TEXTURE_LOD``: TRUE if shader sparse texture sample instruction support clamp the minimal lod to prevent read from un-committed pages.
|
||||
* ``PIPE_CAP_ALLOW_DRAW_OUT_OF_ORDER``: TRUE if the driver allows the "draw out of order" optimization to be enabled. See _mesa_update_allow_draw_out_of_order for more details.
|
||||
|
|
|
|||
|
|
@ -899,9 +899,9 @@ XXX doesn't look like most of the opcodes really belong here.
|
|||
|
||||
.. opcode:: TXF - Texel Fetch
|
||||
|
||||
As per NV_gpu_program4, extract a single texel from a specified texture
|
||||
image or PIPE_BUFFER resource. The source sampler may not be a CUBE or
|
||||
SHADOW. *src0* is a
|
||||
As per :ext:`GL_NV_gpu_program4`, extract a single texel from a specified
|
||||
texture image or PIPE_BUFFER resource. The source sampler may not be a
|
||||
CUBE or SHADOW. *src0* is a
|
||||
four-component signed integer vector used to identify the single texel
|
||||
accessed. 3 components + level. If the texture is multisampled, then
|
||||
the fourth component indicates the sample, not the mipmap level.
|
||||
|
|
@ -915,11 +915,11 @@ XXX doesn't look like most of the opcodes really belong here.
|
|||
|
||||
.. opcode:: TXQ - Texture Size Query
|
||||
|
||||
As per NV_gpu_program4, retrieve the dimensions of the texture depending on
|
||||
the target. For 1D (width), 2D/RECT/CUBE (width, height), 3D (width, height,
|
||||
depth), 1D array (width, layers), 2D array (width, height, layers).
|
||||
Also return the number of accessible levels (last_level - first_level + 1)
|
||||
in W.
|
||||
As per :ext:`GL_NV_gpu_program4`, retrieve the dimensions of the texture
|
||||
depending on the target. For 1D (width), 2D/RECT/CUBE (width, height),
|
||||
3D (width, height, depth), 1D array (width, layers), 2D array (width,
|
||||
height, layers). Also return the number of accessible levels
|
||||
(last_level - first_level + 1) in W.
|
||||
|
||||
For components which don't return a resource dimension, their value
|
||||
is undefined.
|
||||
|
|
@ -951,15 +951,15 @@ XXX doesn't look like most of the opcodes really belong here.
|
|||
|
||||
.. opcode:: TG4 - Texture Gather
|
||||
|
||||
As per ARB_texture_gather, gathers the four texels to be used in a bi-linear
|
||||
filtering operation and packs them into a single register. Only works with
|
||||
2D, 2D array, cubemaps, and cubemaps arrays. For 2D textures, only the
|
||||
addressing modes of the sampler and the top level of any mip pyramid are
|
||||
used. Set W to zero. It behaves like the TEX instruction, but a filtered
|
||||
sample is not generated. The four samples that contribute to filtering are
|
||||
placed into XYZW in clockwise order, starting with the (u,v) texture
|
||||
coordinate delta at the following locations (-, +), (+, +), (+, -), (-, -),
|
||||
where the magnitude of the deltas are half a texel.
|
||||
As per :ext:`GL_ARB_texture_gather`, gathers the four texels to be used in a
|
||||
bi-linear filtering operation and packs them into a single register.
|
||||
Only works with 2D, 2D array, cubemaps, and cubemaps arrays. For 2D
|
||||
textures, only the addressing modes of the sampler and the top level of any
|
||||
mip pyramid are used. Set W to zero. It behaves like the TEX instruction,
|
||||
but a filtered sample is not generated. The four samples that contribute to
|
||||
filtering are placed into XYZW in clockwise order, starting with the (u,v)
|
||||
texture coordinate delta at the following locations (-, +), (+, +), (+, -),
|
||||
(-, -), where the magnitude of the deltas are half a texel.
|
||||
|
||||
PIPE_CAP_TEXTURE_SM5 enhances this instruction to support shadow per-sample
|
||||
depth compares, single component selection, and a non-constant offset. It
|
||||
|
|
@ -3537,7 +3537,7 @@ TGSI_SEMANTIC_VIEWPORT_MASK
|
|||
"""""""""""""""""""""""""""
|
||||
|
||||
A bit mask of viewports to broadcast the current primitive to. See
|
||||
GL_NV_viewport_array2 for more details.
|
||||
:ext:`GL_NV_viewport_array2` for more details.
|
||||
|
||||
|
||||
TGSI_SEMANTIC_TESS_DEFAULT_OUTER_LEVEL
|
||||
|
|
@ -3666,7 +3666,7 @@ If LOWER_LEFT, the position will be (0,0) at the lower left corner and
|
|||
increase upward and rightward.
|
||||
|
||||
OpenGL defaults to LOWER_LEFT, and is configurable with the
|
||||
GL_ARB_fragment_coord_conventions extension.
|
||||
:ext:`GL_ARB_fragment_coord_conventions` extension.
|
||||
|
||||
DirectX 9/10 use UPPER_LEFT.
|
||||
|
||||
|
|
@ -3684,7 +3684,7 @@ rasterization, which is instead controlled by half_pixel_center in the
|
|||
rasterizer.
|
||||
|
||||
OpenGL defaults to HALF_INTEGER, and is configurable with the
|
||||
GL_ARB_fragment_coord_conventions extension.
|
||||
:ext:`GL_ARB_fragment_coord_conventions` extension.
|
||||
|
||||
DirectX 9 uses INTEGER.
|
||||
DirectX 10 uses HALF_INTEGER.
|
||||
|
|
|
|||
|
|
@ -66,8 +66,8 @@ November 2002: Mesa 5.0 is released. It implements the OpenGL 1.4
|
|||
specification.
|
||||
|
||||
January 2003: Mesa 6.0 is released. It implements the OpenGL 1.5
|
||||
specification as well as the GL_ARB_vertex_program and
|
||||
GL_ARB_fragment_program extensions.
|
||||
specification as well as the :ext:`GL_ARB_vertex_program` and
|
||||
:ext:`GL_ARB_fragment_program` extensions.
|
||||
|
||||
June 2007: Mesa 7.0 is released, implementing the OpenGL 2.1
|
||||
specification and OpenGL Shading Language.
|
||||
|
|
|
|||
|
|
@ -131,29 +131,29 @@ the sRGB colorspace.
|
|||
When sampling from a texture, the value returned to the shader is in the linear
|
||||
colorspace. The conversion from sRGB happens as part of sampling. In OpenGL,
|
||||
thanks mostly to history, there are various knobs for determining when you
|
||||
should or should not encode or decode sRGB. In 2007, GL_EXT_texture_sRGB added
|
||||
support for sRGB texture formats and was included in OpenGL 2.1. In 2010,
|
||||
GL_EXT_texture_sRGB_decode added a flag to allow you to disable texture
|
||||
decoding so that the shader received the data still in the sRGB colorspace.
|
||||
Then, in 2012, GL_ARB_texture_view came along and made
|
||||
GL_EXT_texture_sRGB_decode simultaneously obsolete and very confusing. Now,
|
||||
thanks to the combination of extensions, you can upload a texture as linear,
|
||||
create an sRGB view of it and ask that sRGB not be decoded. What format is it
|
||||
in again?
|
||||
should or should not encode or decode sRGB. In 2007, :ext:`GL_EXT_texture_sRGB`
|
||||
added support for sRGB texture formats and was included in OpenGL 2.1. In
|
||||
2010, :ext:`GL_EXT_texture_sRGB_decode` added a flag to allow you to disable
|
||||
texture decoding so that the shader received the data still in the sRGB
|
||||
colorspace. Then, in 2012, :ext:`GL_ARB_texture_view` came along and made
|
||||
:ext:`GL_EXT_texture_sRGB_decode` simultaneously obsolete and very confusing.
|
||||
Now, thanks to the combination of extensions, you can upload a texture as
|
||||
linear, create an sRGB view of it and ask that sRGB not be decoded. What
|
||||
format is it in again?
|
||||
|
||||
The situation with render targets is a bit different. Historically, you got
|
||||
your render target from the window system (which is always sRGB) and the spec
|
||||
said nothing whatsoever about encoding. All render targets were sRGB because
|
||||
that's how monitors worked and application writers were expected to understand
|
||||
that their final rendering needed to be in sRGB. However, with the advent of
|
||||
EXT_framebuffer_object this was no longer true. Also, sRGB was causing
|
||||
:ext:`GL_EXT_framebuffer_object` this was no longer true. Also, sRGB was causing
|
||||
problems with blending because GL was blind to the fact that the output was
|
||||
sRGB and blending was occurring in the wrong colorspace. In 2006, a set of
|
||||
EXT_framebuffer_sRGB extensions added support (on both the GL and window-system
|
||||
sides) for detecting whether a particular framebuffer was in sRGB and
|
||||
instructing GL to do the conversion into the sRGB colorspace as the final step
|
||||
prior to writing out to the render target. Enabling sRGB also implied that
|
||||
blending would occur in the linear colorspace prior to sRGB conversion and
|
||||
:ext:`GL_EXT_framebuffer_sRGB` extensions added support (on both the GL and
|
||||
window-system sides) for detecting whether a particular framebuffer was in sRGB
|
||||
and instructing GL to do the conversion into the sRGB colorspace as the final
|
||||
step prior to writing out to the render target. Enabling sRGB also implied
|
||||
that blending would occur in the linear colorspace prior to sRGB conversion and
|
||||
would therefore be more accurate. When sRGB was added to the OpenGL ES spec in
|
||||
3.1, they added the query for sRGB but did not add the flag to allow you to
|
||||
turn it on and off.
|
||||
|
|
|
|||
|
|
@ -71,9 +71,9 @@ language.
|
|||
|
||||
Several GLSL extensions are also supported:
|
||||
|
||||
- GL_ARB_draw_buffers
|
||||
- GL_ARB_fragment_coord_conventions
|
||||
- GL_ARB_shader_bit_encoding
|
||||
- :ext:`GL_ARB_draw_buffers`
|
||||
- :ext:`GL_ARB_fragment_coord_conventions`
|
||||
- :ext:`GL_ARB_shader_bit_encoding`
|
||||
|
||||
Unsupported Features
|
||||
--------------------
|
||||
|
|
@ -95,7 +95,8 @@ Implementation Notes
|
|||
--------------------
|
||||
|
||||
- Shading language programs are compiled into low-level programs very
|
||||
similar to those of GL_ARB_vertex/fragment_program.
|
||||
similar to those of :ext:`GL_ARB_vertex_program` /
|
||||
:ext:`GL_ARB_fragment_program`.
|
||||
- All vector types (vec2, vec3, vec4, bvec2, etc) currently occupy full
|
||||
float[4] registers.
|
||||
- Float constants and variables are packed so that up to four floats
|
||||
|
|
@ -142,7 +143,7 @@ After building Mesa, the compiler can be found at
|
|||
src/compiler/glsl/glsl_compiler
|
||||
|
||||
Here's an example of using the compiler to compile a vertex shader and
|
||||
emit GL_ARB_vertex_program-style instructions:
|
||||
emit :ext:`GL_ARB_vertex_program`-style instructions:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ somewhat dated, unfortunately.
|
|||
superseded by SGI SI GLU).
|
||||
- **Holger Waechtler** contributed AMD 3DNow! assembly code which
|
||||
accelerates vertex transformation in Mesa 3.1. Holger also
|
||||
implemented the GL_EXT_texture_env_combine extension.
|
||||
implemented the :ext:`GL_EXT_texture_env_combine` extension.
|
||||
- **Jeroen van der Zijp** and **Thorsten Ohl** contributed the Xt/Motif
|
||||
widget code.
|
||||
- **John Stone** provided the multi-threading support in Mesa 3.0.
|
||||
|
|
|
|||
|
|
@ -37,10 +37,8 @@ Catia-03 tests 3, 4, 8
|
|||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
These tests use features of the
|
||||
`GL_NV_fragment_program2 <https://www.opengl.org/registry/specs/NV/fragment_program2.txt>`__
|
||||
and
|
||||
`GL_NV_vertex_program3 <https://www.opengl.org/registry/specs/NV/vertex_program3.txt>`__
|
||||
extensions without checking if the driver supports them.
|
||||
:ext:`GL_NV_fragment_program2` and :ext:`GL_NV_vertex_program3` extensions
|
||||
without checking if the driver supports them.
|
||||
|
||||
When Mesa tries to compile the vertex/fragment programs it generates
|
||||
errors (which Viewperf ignores). Subsequent drawing calls become no-ops
|
||||
|
|
@ -49,9 +47,7 @@ and the rendering is incorrect.
|
|||
sw-02 tests 1, 2, 4, 6
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
These tests depend on the
|
||||
`GL_NV_primitive_restart <https://www.opengl.org/registry/specs/NV/primitive_restart.txt>`__
|
||||
extension.
|
||||
These tests depend on the :ext:`GL_NV_primitive_restart` extension.
|
||||
|
||||
If the Mesa driver doesn't support this extension the rendering will be
|
||||
incorrect and the test will fail.
|
||||
|
|
@ -211,11 +207,11 @@ catia-04
|
|||
~~~~~~~~
|
||||
|
||||
One of the catia tests calls wglGetProcAddress() to get some
|
||||
GL_EXT_direct_state_access functions (such as glBindMultiTextureEXT) and
|
||||
some GL_NV_half_float functions (such as glMultiTexCoord3hNV). If the
|
||||
extension/function is not supported, wglGetProcAddress() can return
|
||||
NULL. Unfortunately, Viewperf doesn't check for null pointers and
|
||||
crashes when it later tries to use the pointer.
|
||||
:ext:`GL_EXT_direct_state_access` functions (such as
|
||||
glBindMultiTextureEXT) and some :ext:`GL_NV_half_float` functions (such
|
||||
as glMultiTexCoord3hNV). If the extension/function is not supported,
|
||||
wglGetProcAddress() can return NULL. Unfortunately, Viewperf doesn't check
|
||||
for null pointers and crashes when it later tries to use the pointer.
|
||||
|
||||
Another catia test uses OpenGL 3.1's primitive restart feature. But when
|
||||
Viewperf creates an OpenGL context, it doesn't request version 3.1 If
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue