1XXX - incomplete (needs number, glx protocol) 2 3Name 4 5 SGIX_fragments_instrument 6 7Name Strings 8 9 GL_SGIX_fragments_instrument 10 11Version 12 13 $Date: 1999/04/27 01:20:04 $ $Revision: 1.5 $ 14 15Number 16 17 180 18 19Dependencies 20 21 SGIX_instruments is required 22 23Overview 24 25 This extension defines an instrument that uses the API defined in 26 SGIX_instruments. The instrument specified by this extension is a 27 counter of the number of fragments generated during pixel and 28 geometry rasterization. The maximum value of the counter is an 29 implementation-dependent constant. 30 31 Some systems may maintain counters on different parts of the 32 system. For example, a system with rasterization distributed 33 across multiple chips may maintain a count of the fragments 34 generated on each individual chip. In this extension, a queriable 35 constant is defined that indicates the number of responses to 36 expect when a measurement is taken. This mechanism allows GL 37 implementations to be as efficient as possible. 38 39Issues 40 41 * If an operation such as a clear is implemented 42 internally as a draw operation but according to the GL spec 43 does not generate any fragments, should the counter be 44 updated? Updating would give a less accurate idea of 45 fragments generated from a GL spec point of view, but would 46 give a more accurate idea of rasterizer load during a given 47 interval. 48 49 A: It's better to keep the single meaning of GL fragments 50 generated. Counting internal fragments wouldn't always be 51 a good measure of rasterizer load and more accurate 52 mechanisms can be imagined easily. 53 54 * Having each counter response appear as an independent 55 instrument is awkward and wastes space in the buffer. Could 56 we have GL combine them? 57 58 A: See explanation in depth_pass_instrument spec. 59 60 * We say that invisible fragments culled early as an 61 implementation optimization do not need to be counted. For 62 example, if an entire triangle is not visible an 63 implementation can not rasterize it and not count the 64 fragments it contains. From a GL point of view, these 65 fragments *were* generated, but counting them would require 66 really generating them (in most implementations anyway). 67 68 A: This extension is aimed at performance-sensitive applications, 69 so slowing stuff down is not a good idea. Just don't 70 count them. 71 72 * Is the name for this extension ok? It's not very descriptive 73 but the more descriptive names suggested all came out rather 74 long (eg FRAGMENTS_GENERATED_INSTRUMENT_SGIX). 75 76New Tokens 77 78 Accepted by the <cap> parameter of Enable, Disable and IsEnabled: 79 80 FRAGMENTS_INSTRUMENT_SGIX 0x8313 81 82 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, 83 GetFloatv, and GetDoublev: 84 85 FRAGMENTS_INSTRUMENT_COUNTERS_SGIX 0x8314 86 FRAGMENTS_INSTRUMENT_MAX_SGIX 0x8315 87 88Additions to Chapter 2 of the 1.0 Specification (OpenGL Operation) 89 90 None 91 92Additions to Chapter 3 of the 1.0 Specification (Rasterization) 93 94 Add a section 3.X (The Fragment Instrument) after the section 3.1 95 (Invariance): 96 97 If FRAGMENTS_INSTRUMENT_SGIX is enabled and instruments have been 98 started via a call to StartInstrumentSGIX, a counter or counters 99 of the number of fragments generated by rasterization (geometry or 100 pixel rectangle) is maintained. The number of counters can be 101 queried using the token FRAGMENTS_INSTRUMENT_COUNTERS_SGIX. The 102 fragments are counted at the end of the rasterization stage just 103 before per-fragment operations are applied. For each fragment, 104 the counter is incremented by one. If the increment would have 105 caused the counter to go beyond is maximum representable value, 106 the count is clamped to the maximum. The maximum value of the 107 counters may be queried using FRAGMENTS_INSTRUMENT_MAX_SGIX. The 108 counter values are unsigned, so FRAGMENTS_INSTRUMENT_MAX_SGIX may 109 be as high as the maximum value of an unsigned integer. 110 111 Some GL implementations may detect early that a fragment or set of 112 fragments will not effect the contents of the frame buffer and 113 therefore will get a performance increase by not generating them. 114 For example, an entire triangle may be in a region of the frame 115 buffer that is covered by another window. Previously, this type of 116 optimization had been invisible from a GL spec point of view and 117 could be detected by the application only as a change in 118 performance. It is legal for an implementation to not increment 119 the counter for fragments that have been eliminated due to this 120 sort of optimization. However, a fragment must be counted if it 121 will effect frame buffer contents. 122 123 If an implementation can detect during rasterization that a 124 fragment (or set of fragments) will not 125 effect the contents of the frame buffer, the implementation can 126 transparently avoid rasterizing the . It is legal for an implementation to not increment the 127 fragment counter in this case. 128 129Additions to Chapter 4 of the 1.0 Specification (Per-Fragment Operations 130and the Frame Buffer) 131 132 None 133 134Additions to Chapter 5 of the 1.0 Specification (Special Functions) 135 136 Add to the end of section 5.X entitled Instruments: 137 138 The instrument FRAGMENTS_INSTRUMENT_SGIX returns for each 139 measurement a system-dependent constant number of responses to the 140 buffer. The constant may be queried using the Get with an 141 argument of FRAGMENTS_INSTRUMENT_COUNTERS_SGIX. Each response is 142 formatted as though it came from an independent instrument. If 143 more than one instrument is enabled, the responses from the depth 144 pass instrument will be placed successively (as opposed to 145 possibly being interrupted by responses from other instruments). 146 147 FRAGMENTS_INSTRUMENT_SGIX responses are formatted as follows 148 (starting at the first word): 149 150 FRAGMENTS_INSTRUMENT_SGIX 151 Number of int's in the response (4) 152 Counter value 153 Marker value 154 155 The counter value is padded to the size of an int if necessary by 156 zero-filling the most significant bits. 157 158 Assuming that none of the counters overflowed, the total number of 159 fragments generated while the instrument was enabled is equal to 160 the sum of all the counter values. 161 162 Although different responses come from different hardware 163 counters, they should be considered identical by the software and 164 no guarantee is made about how the responses for each counter are 165 ordered within a single query response. For example, a hardware 166 implementation may maintain a counter for each quadrant of the 167 screen, but which response in the buffer came from which counter 168 is not exposed to the application. 169 170 171Additions to Chapter 6 of the 1.0 Specification (State and State Requests) 172 173 None 174 175Additions to the GLX Specification 176 177 XXX 178 179Errors 180 181 None 182 183New State 184 185 Get Value Get Command Type Initial Value Attribute 186 --------- ----------- ---- ------------- --------- 187 FRAGMENTS_INSTRUMENT_SGIX ReadInstrumentsSGIX 1*xZ+ 0 - 188 189New Implementation Dependent State 190 191 Get Value Get Command Type Minimum Value 192 --------- ----------- ---- ------------- 193 FRAGMENTS_INSTRUMENT_COUNTERS_SGIX GetIntegerv Z+ 1 194 195