Vulkan-Docs/appendices/VK_NV_representative_fragme...

118 lines
4.3 KiB
Plaintext
Raw Normal View History

Change log for September 19, 2018 Vulkan 1.1.85 spec update: * Update release number to 85. Public Issues: * Add self-dependency ename:VK_DEPENDENCY_BY_REGION_BIT valid usage statements for slink:VkSubpassDependency(public pull request 778). * Apply fix from pull request 742 to slink:VkSubpassDependency and slink:VkSubpassDependency2 (public pull request 779). * Specify the units of slink:VkBufferImageCopy::pname:bufferRowLength and pname:bufferImageHeight as texels (public pull request 781). * Better specify promoted parameter mapping in the `<<VK_KHR_create_renderpass2>>` appendix (public pull request 782). Internal Issues: * Only include the <<fundamentals-validusage-versions, Valid Usage for Newer Core Versions>> section in Vulkan 1.1 or later (internal issue 1381). Other Issues: * Clean up redundant valid usage language for the `VK_ANDROID_external_memory_android_hardware_buffer` extension interaction with slink:VkImageCreateInfo. * Fix error in a flag name within valid usage statements for slink:VkMemoryAllocateInfo. * Clarify that memory types are not totally ordered in slink:VkPhysicalDeviceMemoryProperties. * For slink:VkWriteDescriptorSetInlineUniformBlockEXT, set structextends="VkWriteDescriptorSet" in `vk.xml`, and make slink:VkDescriptorSetLayoutBindingFlagsCreateInfoEXT::pname:pBindingFlags optional. * Add documentation of 'provisional' XML attribute to registry.txt. New Extensions: * `VK_NV_compute_shader_derivatives` * `VK_NV_corner_sampled_image` * `VK_NV_fragment_shader_barycentric` * `VK_NV_mesh_shader` * `VK_NV_representative_fragment_test` * `VK_NV_scissor_exclusive` * `VK_NV_shader_image_footprint` * `VK_NV_shading_rate_image` * `VK_NVX_raytracing`
2018-09-16 01:35:16 +00:00
include::meta/VK_NV_representative_fragment_test.txt[]
*Last Modified Date*::
2018-09-13
*Contributors*::
- Kedarnath Thangudu, NVIDIA
- Christoph Kubisch, NVIDIA
- Pierre Boudier, NVIDIA
- Pat Brown, NVIDIA
- Jeff Bolz, NVIDIA
- Eric Werness, NVIDIA
This extension provides a new representative fragment test that allows
implementations to reduce the amount of rasterization and fragment
processing work performed for each point, line, or triangle primitive.
For any primitive that produces one or more fragments that pass all other
early fragment tests, the implementation is permitted to choose one or more
"representative" fragments for processing and discard all other fragments.
For draw calls rendering multiple points, lines, or triangles arranged in
lists, strips, or fans, the representative fragment test is performed
independently for each of those primitives.
This extension is useful for applications that use an early render pass to
determine the full set of primitives that would be visible in the final
scene.
In this render pass, such applications would set up a fragment shader that
enables early fragment tests and writes to an image or shader storage buffer
to record the ID of the primitive that generated the fragment.
Without this extension, the shader would record the ID separately for each
visible fragment of each primitive.
With this extension, fewer stores will be performed, particularly for large
primitives.
The representative fragment test has no effect if early fragment tests are
not enabled via the fragment shader.
The set of fragments discarded by the representative fragment test is
implementation-dependent and may vary from frame to frame.
In some cases, the representative fragment test may not discard any
fragments for a given primitive.
=== New Object Types
None.
=== New Enum Constants
* Extending elink:VkStructureType
** ename:VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_REPRESENTATIVE_FRAGMENT_TEST_FEATURES_NV
** ename:VK_STRUCTURE_TYPE_PIPELINE_REPRESENTATIVE_FRAGMENT_TEST_STATE_CREATE_INFO_NV
=== New Enums
None.
=== New Structures
* slink:VkPhysicalDeviceRepresentativeFragmentTestFeaturesNV
* slink:VkPipelineRepresentativeFragmentTestStateCreateInfoNV
=== New Functions
None.
=== Issues
(1) Is the representative fragment test guaranteed to have any effect?
**RESOLVED**: No.
As specified, we only guarantee that each primitive with at least one
fragment that passes prior tests will have one fragment passing the
representative fragment tests.
We don't guarantee that any particular fragment will fail the test.
In the initial implementation of this extension, the representative fragment
test is treated as an optimization that may be completely disabled for some
pipeline states.
This feature was designed for a use case where the fragment shader records
information on individual primitives using shader storage buffers or storage
images, with no writes to color or depth buffers.
(2) Will the set of fragments that pass the representative fragment test be
repeatable if you draw the same scene over and over again?
**RESOLVED**: No.
The set of fragments that pass the representative fragment test is
implementation-dependent and may vary due to the timing of operations
performed by the GPU.
(3) What happens if you enable the representative fragment test with writes
to color and/or depth render targets enabled?
**RESOLVED**: If writes to the color or depth buffer are enabled, they will
be performed for any fragments that survive the relevant tests.
Any fragments that fail the representative fragment test will not update
color buffers.
For the use cases intended for this feature, we don't expect color or depth
writes to be enabled.
(4) How do derivatives and automatic texture level of detail computations
work with the representative fragment test enabled?
**RESOLVED**: If a fragment shader uses derivative functions or texture
lookups using automatic level of detail computation, derivatives will be
computed identically whether or not the representative fragment test is
enabled.
For the use cases intended for this feature, we don't expect the use of
derivatives in the fragment shader.
=== Version History
* Revision 2, 2018-09-13 (pbrown)
- Add issues.
* Revision 1, 2018-08-22 (Kedarnath Thangudu)
- Internal Revisions