1XXX - incomplete (needs number, glx protocol, enumerant values) 2 3Name 4 5 SGIX_depth_pass_instrument 6 7Name Strings 8 9 GL_SGIX_depth_pass_instrument 10 11Version 12 13 Last Modified Date: 10/21/1998 14 $Date: 1998/10/21 19:08:52 $ $Revision: 1.4 $ 15 16Number 17 18 205 19 20Dependencies 21 22 SGIX_instruments is required 23 SGIX_multisample affects the definition of this extension. 24 25Overview 26 27 This extension defines an instrument that uses the API defined in 28 SGIX_instruments. The instrument specified by this extension is a 29 counter of the number of fragments which passed the Z test during 30 rasterization. The maximum value of the counter is an 31 implementation-dependent constant. 32 33 Some systems may maintain counters on different parts of the 34 system. For example, a system with a frame buffer distributed 35 across multiple chips may maintain a count of the fragments which 36 passed the depth test on each individual chip. In this extension, 37 a queriable constant is defined that indicates the number of 38 responses to expect when a measurement is taken. This 39 mechanism allows GL implementations to be as efficient as possible. 40 41Issues 42 43 * Should we count fragments drawn when the depth test was 44 disabled? 45 46 A: Doesn't seem to be a strong reason to do this one way or 47 the other -- let's treat disabled depth test the same as a 48 depth func of ALWAYS. 49 50 * Should we guarantee that if other counters are enabled when the 51 query is issued, the depth pass responses are placed 52 successively in the buffer? This might make interpreting the 53 buffer easier but would complicate and slightly slow the 54 OpenGL implementation. 55 56 A: They should be successive. The GL burden shouldn't be that 57 great since the buffer can be reordered during the 58 PollInstrumentsSGIX command. This way we can probably 59 avoid moving the contents of the entire buffer around and 60 also keep the resource allocation burden in the 61 application. 62 63 * Having each counter response appear as an independent 64 instrument is awkward and wastes space in the buffer. Could 65 we have GL combine them?? 66 67 A: No. It will be natural for some hardware implementations 68 to have multiple instruments returned in a non-guaranteed 69 order using a DMA. In this case the implementation will 70 need a way to differentiate the responses -- ie, a header. 71 By putting the header for each instrument in the 72 application's buffer, we allow the DMA destination to be 73 the user's buffer. Combining the responses would 74 complicate allocation since space would be required for 75 them and would be slower since it would require more data 76 movement. 77 78 * Should the counter value be considered state? 79 SGIX_ir_instrument1 doesn't list its counters as state. 80 81 A: Seems like SGIX_ir_instrument1 may be wrong -- this seems 82 like it should be state. Note that histogram and minmax 83 contents are state. 84 85 * In theory should we add something to the GLX protocol? 86 SGIX_instruments doesn't establish a framework yet so it's 87 kind of a moot point. 88 89New Tokens 90 91 Accepted by the <cap> parameter of Enable, Disable and IsEnabled: 92 93 DEPTH_PASS_INSTRUMENT_SGIX 0x8310 94 95 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, 96 GetFloatv, and GetDoublev: 97 98 DEPTH_PASS_INSTRUMENT_COUNTERS_SGIX 0x8311 99 DEPTH_PASS_INSTRUMENT_MAX_SGIX 0x8312 100 101Additions to Chapter 2 of the 1.0 Specification (OpenGL Operation) 102 103 None 104 105Additions to Chapter 3 of the 1.0 Specification (Rasterization) 106 107 None 108 109Additions to Chapter 4 of the 1.0 Specification (Per-Fragment Operations 110and the Frame Buffer) 111 112 Added to subsection 4.1.5 (Depth buffer test) at the end of the 113 paragraph which begins "If the depth buffer test fails...": 114 115 If DEPTH_PASS_INSTRUMENT_SGIX is enabled and instruments have been 116 started via a call to StartInstrumentSGIX, a counter or counters 117 of the number of fragments which have passed the depth test or 118 which have been drawn when the depth test is disabled is 119 maintained. The number of counters can be queried using the token 120 DEPTH_PASS_INSTRUMENT_COUNTERS_SGIX. For each fragment which 121 passes the depth test or is drawn with depth testing disabled, one 122 counter is incremented by one. If MULTISAMPLE_SGIS is enabled, 123 the counter is incremented by one for each fragment containing at 124 least one sample for which the depth test passed. If the 125 increment would have caused the counter to go beyond is maximum 126 representable value, the count is clamped to the maximum. The 127 maximum value of the counters may be queried using 128 DEPTH_PASS_INSTRUMENT_MAX_SGIX. The counter values are unsigned, 129 so DEPTH_PASS_INSTRUMENT_MAX_SGIX may be as high as the maximum 130 value of an unsigned integer. 131 132Additions to Chapter 5 of the 1.0 Specification (Special Functions) 133 134 Add to the end of section 5.X entitled Instruments: 135 136 The instrument DEPTH_PASS_INSTRUMENT_SGIX returns for each 137 measurement a system-dependent constant number of responses to the 138 buffer. The constant may be queried using the Get with an 139 argument of DEPTH_PASS_INSTRUMENT_COUNTERS_SGIX. Each response is 140 formatted as though it came from an independent instrument. If 141 more than one instrument is enabled, the responses from the depth 142 pass instrument will be placed successively (as opposed to 143 possibly being interrupted by responses from other instruments). 144 145 DEPTH_PASS_INSTRUMENT_SGIX responses are formatted as follows 146 (starting at the first word): 147 148 DEPTH_PASS_INSTRUMENT_SGIX 149 Number of int's in the response (4) 150 Counter value 151 Marker value 152 153 The counter value is padded to the size of an unsigned int if 154 necessary by zero-filling the most significant bits. 155 156 Assuming that none of the counters overflowed, the total number of 157 fragments that passed the depth test while the instrument was 158 enabled is equal to the sum of all the counter values. 159 160 Although different responses come from different hardware 161 counters, they should be considered identical by the software and 162 no guarantee is made about how the responses for each counter are 163 ordered within a single query response. For example, a hardware 164 implementation may maintain a counter for each quadrant of the 165 screen, but which response in the buffer came from which counter 166 is not exposed to the application. 167 168Additions to Chapter 6 of the 1.0 Specification (State and State Requests) 169 170 None 171 172Additions to the GLX Specification 173 174 XXX 175 176Errors 177 178 None 179 180New State 181 182 Get Value Get Command Type Initial Value Attribute 183 --------- ----------- ---- ------------- --------- 184 DEPTH_PASS_INSTRUMENT_SGIX ReadInstrumentsSGIX 1*xZ+ 0 - 185 186New Implementation Dependent State 187 188 Get Value Get Command Type Minimum Value 189 --------- ----------- ---- ------------- 190 DEPTH_PASS_INSTRUMENT_COUNTERS_SGIX GetIntegerv Z+ 1 191