mirror of
https://github.com/status-im/Vulkan-Docs.git
synced 2025-01-22 04:09:25 +00:00
256a1ef661
* Update release number to 93.
Public Issues:
* Add spec language for ename:VK_INDEX_TYPE_NONE_NV and fix up
slink:VkAccelerationStructureTypeNV (public issue 848).
* Add missing suffix in description of slink:VkSubpassDescription2KHR
parameters (public pull request 851).
* Fix miscellaneous typos (public pull request 855).
* Add driver ID for Pastel (public pull request 856).
* Add missing include directive for slink:VkMemoryWin32HandlePropertiesKHR
implicit valid usage statements (public pull request 857).
Internal Issues:
* Restrict the storage classes permitted for SPIR-V atomics to what is
actually supported, in the <<spirvenv-module-validation, Validation
Rules within a Module>> section (internal issue 1123).
* Add a missing Valid Usage statement to slink:VkRenderPassCreateInfo for
the case pname:stencilLoadOp == ename:VK_LOAD_OP_CLEAR, pname:layout ==
ename:VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL (internal issue
1408).
* Modify optimize-pdf script and Makefile to retain non-optimized original
PDF on errors (internal issue 1435).
* Add <<spirvenv-module-validation, SPIR-V validation rules>> stating that
only the listed code:BuiltIn decorations are permitted, and only when
relevante features and extensions are enabled (internal issue 1449).
* Remove some duplicated Valid Usage IDs created via cut & paste error
(internal issue 1455).
* Build HTML output for extension reference pages (internal issue 1461).
** Improve genRef.py handling of aliases defined inside other refpages.
** Emit aliases in pygenerator.py.
** Add XML noautovalidity flag for VkRenderPassCreateFlags until there
are some corresponding FlagBits defined.
** Corrected types= attribute on some refpage blocks to 'flags'
** Added refpage blocks for some missing types detected by CI tests.
* Fixed many Valid Usage statement issues in slink:VkRenderPassCreateInfo,
slink:VkSubpassDescription, slink:VkSubpassDescription2KHR,
slink:VkSubpassDependency2KHR, flink:vkCmdBeginRenderPass,
flink:vkCmdBeginRenderPass2KHR, and slink:VkRenderPassBeginInfo
discovered while adding `VK_KHR_create_renderpass2` to the validation
layers.
New Extensions:
* `VK_EXT_scalar_block_layout`
* `VK_EXT_separate_stencil_usage`
116 lines
4.3 KiB
Plaintext
116 lines
4.3 KiB
Plaintext
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
|