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