Name NV_representative_fragment_test Name Strings GL_NV_representative_fragment_test Contacts Christoph Kubisch, NVIDIA Corporation (ckubisch 'at' nvidia.com) Kedarnath Thangudu, NVIDIA Corporation (kthangudu 'at' nvidia.com) Contributors Jeff Bolz, NVIDIA Corporation Pat Brown, NVIDIA Corporation Eric Werness, NVIDIA Corporation Pyarelal Knowles, NVIDIA Corporation Status Shipping Version Last Modified Date: March 7, 2019 NVIDIA Revision: 3 Number OpenGL Extension #528 OpenGL ES Extension #314 Dependencies This extension is written against the OpenGL 4.6 Specification (Compatibility Profile), dated May 14, 2018. OpenGL 4.5 or OpenGL ES 3.2 is required. Overview 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 Procedures and Functions None New Tokens Accepted by the parameter of Enable, Disable, and IsEnabled, and by the parameter of GetBooleanv, GetIntegerv, GetFloatv, and GetDoublev: REPRESENTATIVE_FRAGMENT_TEST_NV 0x937F Modifications to the OpenGL 4.6 Specification (Compatibility Profile) Modify Section 14.9, Early Per-Fragment Tests (p. 578) (modify second pararaph of the section, p. 578, to document that there are now four optional early fragment tests) Three fragment operations are performed, and a further four are optionally performed on each fragment, ... (modify the last paragraph, p. 578, to list the new early fragment test) If early per-fragment operations are enabled, these tests are also performed: * the stencil test (see section 17.3.3); * the depth buffer test (see section 17.3.4); and * the representative fragment test (see section 17.3.X) * occlusion query sample counting (see section 17.3.5) Modify Section 14.9.4, The Early Fragment Test Qualifier, p. 582 (modify the first paragraph of the section, p. 582, to enumerate the new test) The stencil test, depth buffer test, representative fragment test, and occlusion query sample counting are performed if and only if early fragment tests are enabled in the active fragment shader (see section 15.2.4). ... Insert new section before Section 17.3.5, Occlusion Queries (p. 614) Section 17.3.X, Representative Fragment Test The representative fragment test 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 prior 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. The set of fragments discarded by the representative fragment test is implementation-dependent. In some cases, the representative fragment test may not discard any fragments for a given primitive. This test is enabled or disabled using Enable or Disable with the target REPRESENTATIVE_FRAGMENT_NV. If early fragment tests (section 15.2.4) are not enabled in the active fragment shader, the representative fragment test has no effect, even if enabled. Additions to the AGL/GLX/WGL Specifications None. New State Get Value Type Get Command Initial Value Description Sec Attribute ------------------------------------ ---- ----------- ------------- ------------------------- ------ -------------- REPRESENTATIVE_FRAGMENT_TEST_NV B IsEnabled GL_FALSE Representative fragment 17.3.X enable test New Implementation Dependent State None Interactions with OpenGL ES If implemented with OpenGL ES, ignore references to GetDoublev. Issues (1) Since the representative fragment test does not have guaranteed behavior, it is sort of a hint. Should we use the existing hint mechanisms for this extension or simply add an enable? RESOLVED: Use an enable. Hints are rarely used in OpenGL, and the "FASTEST" vs. "NICEST" vs. "DONT_CARE" doesn't map reasonably to the representative fragment test. (2) Should this functionality be exposed as a sub-feature of the depth or stencil tests, as its own separate per-fragment test, or as some piece of state controlling primitive rasterization? RESOLVED: Expose as a per-fragment test. This test is largely orthogonal to depth testing, other than it is supposed to run after the depth testing. So coupling it to the depth test doesn't make sense. Coupling the feature to rasterization also doesn't make too much sense, because the rasterization pipeline stage discarding fragments for this test would depend on a later pipeline stages performing other per-fragment tests (such as the depth test). Revision History Revision 3, March 7, 2019 (pknowles) - Add ES interactions. Revision 2, September 15, 2018 (pbrown) - Prepare specification for publication. Revision 1 (ckubisch and kthangudu) - Internal Revisions