blob: a77d71ba0db59a36bda98fd7e7a6ecf34305b596 [file] [log] [blame]
XXX - incomplete (needs number, glx protocol)
Name Strings
$Date: 1999/04/27 01:20:04 $ $Revision: 1.5 $
SGIX_instruments is required
This extension defines an instrument that uses the API defined in
SGIX_instruments. The instrument specified by this extension is a
counter of the number of fragments generated during pixel and
geometry rasterization. The maximum value of the counter is an
implementation-dependent constant.
Some systems may maintain counters on different parts of the
system. For example, a system with rasterization distributed
across multiple chips may maintain a count of the fragments
generated on each individual chip. In this extension, a queriable
constant is defined that indicates the number of responses to
expect when a measurement is taken. This mechanism allows GL
implementations to be as efficient as possible.
* If an operation such as a clear is implemented
internally as a draw operation but according to the GL spec
does not generate any fragments, should the counter be
updated? Updating would give a less accurate idea of
fragments generated from a GL spec point of view, but would
give a more accurate idea of rasterizer load during a given
A: It's better to keep the single meaning of GL fragments
generated. Counting internal fragments wouldn't always be
a good measure of rasterizer load and more accurate
mechanisms can be imagined easily.
* Having each counter response appear as an independent
instrument is awkward and wastes space in the buffer. Could
we have GL combine them?
A: See explanation in depth_pass_instrument spec.
* We say that invisible fragments culled early as an
implementation optimization do not need to be counted. For
example, if an entire triangle is not visible an
implementation can not rasterize it and not count the
fragments it contains. From a GL point of view, these
fragments *were* generated, but counting them would require
really generating them (in most implementations anyway).
A: This extension is aimed at performance-sensitive applications,
so slowing stuff down is not a good idea. Just don't
count them.
* Is the name for this extension ok? It's not very descriptive
but the more descriptive names suggested all came out rather
New Tokens
Accepted by the <cap> parameter of Enable, Disable and IsEnabled:
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
GetFloatv, and GetDoublev:
Additions to Chapter 2 of the 1.0 Specification (OpenGL Operation)
Additions to Chapter 3 of the 1.0 Specification (Rasterization)
Add a section 3.X (The Fragment Instrument) after the section 3.1
If FRAGMENTS_INSTRUMENT_SGIX is enabled and instruments have been
started via a call to StartInstrumentSGIX, a counter or counters
of the number of fragments generated by rasterization (geometry or
pixel rectangle) is maintained. The number of counters can be
fragments are counted at the end of the rasterization stage just
before per-fragment operations are applied. For each fragment,
the counter is incremented by one. If the increment would have
caused the counter to go beyond is maximum representable value,
the count is clamped to the maximum. The maximum value of the
counters may be queried using FRAGMENTS_INSTRUMENT_MAX_SGIX. The
counter values are unsigned, so FRAGMENTS_INSTRUMENT_MAX_SGIX may
be as high as the maximum value of an unsigned integer.
Some GL implementations may detect early that a fragment or set of
fragments will not effect the contents of the frame buffer and
therefore will get a performance increase by not generating them.
For example, an entire triangle may be in a region of the frame
buffer that is covered by another window. Previously, this type of
optimization had been invisible from a GL spec point of view and
could be detected by the application only as a change in
performance. It is legal for an implementation to not increment
the counter for fragments that have been eliminated due to this
sort of optimization. However, a fragment must be counted if it
will effect frame buffer contents.
If an implementation can detect during rasterization that a
fragment (or set of fragments) will not
effect the contents of the frame buffer, the implementation can
transparently avoid rasterizing the . It is legal for an implementation to not increment the
fragment counter in this case.
Additions to Chapter 4 of the 1.0 Specification (Per-Fragment Operations
and the Frame Buffer)
Additions to Chapter 5 of the 1.0 Specification (Special Functions)
Add to the end of section 5.X entitled Instruments:
The instrument FRAGMENTS_INSTRUMENT_SGIX returns for each
measurement a system-dependent constant number of responses to the
buffer. The constant may be queried using the Get with an
argument of FRAGMENTS_INSTRUMENT_COUNTERS_SGIX. Each response is
formatted as though it came from an independent instrument. If
more than one instrument is enabled, the responses from the depth
pass instrument will be placed successively (as opposed to
possibly being interrupted by responses from other instruments).
FRAGMENTS_INSTRUMENT_SGIX responses are formatted as follows
(starting at the first word):
Number of int's in the response (4)
Counter value
Marker value
The counter value is padded to the size of an int if necessary by
zero-filling the most significant bits.
Assuming that none of the counters overflowed, the total number of
fragments generated while the instrument was enabled is equal to
the sum of all the counter values.
Although different responses come from different hardware
counters, they should be considered identical by the software and
no guarantee is made about how the responses for each counter are
ordered within a single query response. For example, a hardware
implementation may maintain a counter for each quadrant of the
screen, but which response in the buffer came from which counter
is not exposed to the application.
Additions to Chapter 6 of the 1.0 Specification (State and State Requests)
Additions to the GLX Specification
New State
Get Value Get Command Type Initial Value Attribute
--------- ----------- ---- ------------- ---------
New Implementation Dependent State
Get Value Get Command Type Minimum Value
--------- ----------- ---- -------------