Wed, 31 Dec 2014 06:09:35 +0100
Cloned upstream origin tor-browser at tor-browser-31.3.0esr-4.5-1-build1
revision ID fc1c9ff7c1b2defdbc039f12214767608f46423f for hacking purpose.
michael@0 | 1 | Name |
michael@0 | 2 | |
michael@0 | 3 | ANGLE_timer_query |
michael@0 | 4 | |
michael@0 | 5 | Name Strings |
michael@0 | 6 | |
michael@0 | 7 | GL_ANGLE_timer_query |
michael@0 | 8 | |
michael@0 | 9 | Contributors |
michael@0 | 10 | |
michael@0 | 11 | Contributors to ARB_occlusion_query |
michael@0 | 12 | Contributors to EXT_timer_query |
michael@0 | 13 | Contributors to ARB_timer_query |
michael@0 | 14 | Ben Vanik, Google Inc. |
michael@0 | 15 | Daniel Koch, TransGaming Inc. |
michael@0 | 16 | |
michael@0 | 17 | Contact |
michael@0 | 18 | |
michael@0 | 19 | Ben Vanik, Google Inc. (benvanik 'at' google 'dot' com) |
michael@0 | 20 | |
michael@0 | 21 | Status |
michael@0 | 22 | |
michael@0 | 23 | Draft |
michael@0 | 24 | |
michael@0 | 25 | Version |
michael@0 | 26 | |
michael@0 | 27 | Last Modified Date: Apr 28, 2011 |
michael@0 | 28 | Author Revision: 1 |
michael@0 | 29 | |
michael@0 | 30 | Number |
michael@0 | 31 | |
michael@0 | 32 | OpenGL ES Extension #?? |
michael@0 | 33 | |
michael@0 | 34 | Dependencies |
michael@0 | 35 | |
michael@0 | 36 | OpenGL ES 2.0 is required. |
michael@0 | 37 | |
michael@0 | 38 | The extension is written against the OpenGL ES 2.0 specification. |
michael@0 | 39 | |
michael@0 | 40 | Overview |
michael@0 | 41 | |
michael@0 | 42 | Applications can benefit from accurate timing information in a number of |
michael@0 | 43 | different ways. During application development, timing information can |
michael@0 | 44 | help identify application or driver bottlenecks. At run time, |
michael@0 | 45 | applications can use timing information to dynamically adjust the amount |
michael@0 | 46 | of detail in a scene to achieve constant frame rates. OpenGL |
michael@0 | 47 | implementations have historically provided little to no useful timing |
michael@0 | 48 | information. Applications can get some idea of timing by reading timers |
michael@0 | 49 | on the CPU, but these timers are not synchronized with the graphics |
michael@0 | 50 | rendering pipeline. Reading a CPU timer does not guarantee the completion |
michael@0 | 51 | of a potentially large amount of graphics work accumulated before the |
michael@0 | 52 | timer is read, and will thus produce wildly inaccurate results. |
michael@0 | 53 | glFinish() can be used to determine when previous rendering commands have |
michael@0 | 54 | been completed, but will idle the graphics pipeline and adversely affect |
michael@0 | 55 | application performance. |
michael@0 | 56 | |
michael@0 | 57 | This extension provides a query mechanism that can be used to determine |
michael@0 | 58 | the amount of time it takes to fully complete a set of GL commands, and |
michael@0 | 59 | without stalling the rendering pipeline. It uses the query object |
michael@0 | 60 | mechanisms first introduced in the occlusion query extension, which allow |
michael@0 | 61 | time intervals to be polled asynchronously by the application. |
michael@0 | 62 | |
michael@0 | 63 | IP Status |
michael@0 | 64 | |
michael@0 | 65 | No known IP claims. |
michael@0 | 66 | |
michael@0 | 67 | New Procedures and Functions |
michael@0 | 68 | |
michael@0 | 69 | void GenQueriesANGLE(sizei n, uint *ids); |
michael@0 | 70 | void DeleteQueriesANGLE(sizei n, const uint *ids); |
michael@0 | 71 | boolean IsQueryANGLE(uint id); |
michael@0 | 72 | void BeginQueryANGLE(enum target, uint id); |
michael@0 | 73 | void EndQueryANGLE(enum target); |
michael@0 | 74 | void QueryCounterANGLE(uint id, enum target); |
michael@0 | 75 | void GetQueryivANGLE(enum target, enum pname, int *params); |
michael@0 | 76 | void GetQueryObjectivANGLE(uint id, enum pname, int *params); |
michael@0 | 77 | void GetQueryObjectuivANGLE(uint id, enum pname, uint *params); |
michael@0 | 78 | void GetQueryObjecti64vANGLE(uint id, enum pname, int64 *params); |
michael@0 | 79 | void GetQueryObjectui64vANGLE(uint id, enum pname, uint64 *params); |
michael@0 | 80 | |
michael@0 | 81 | New Tokens |
michael@0 | 82 | |
michael@0 | 83 | Accepted by the <pname> parameter of GetQueryivANGLE: |
michael@0 | 84 | |
michael@0 | 85 | QUERY_COUNTER_BITS_ANGLE 0x8864 |
michael@0 | 86 | CURRENT_QUERY_ANGLE 0x8865 |
michael@0 | 87 | |
michael@0 | 88 | Accepted by the <pname> parameter of GetQueryObjectivANGLE, |
michael@0 | 89 | GetQueryObjectuivANGLE, GetQueryObjecti64vANGLE, and |
michael@0 | 90 | GetQueryObjectui64vANGLE: |
michael@0 | 91 | |
michael@0 | 92 | QUERY_RESULT_ANGLE 0x8866 |
michael@0 | 93 | QUERY_RESULT_AVAILABLE_ANGLE 0x8867 |
michael@0 | 94 | |
michael@0 | 95 | Accepted by the <target> parameter of BeginQueryANGLE, EndQueryANGLE, and |
michael@0 | 96 | GetQueryivANGLE: |
michael@0 | 97 | |
michael@0 | 98 | TIME_ELAPSED_ANGLE 0x88BF |
michael@0 | 99 | |
michael@0 | 100 | Accepted by the <target> parameter of GetQueryivANGLE and |
michael@0 | 101 | QueryCounterANGLE: |
michael@0 | 102 | |
michael@0 | 103 | TIMESTAMP_ANGLE 0x8E28 |
michael@0 | 104 | |
michael@0 | 105 | Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL ES Operation) |
michael@0 | 106 | |
michael@0 | 107 | (Modify table 2.1, Correspondence of command suffix letters to GL argument) |
michael@0 | 108 | Add two new types: |
michael@0 | 109 | |
michael@0 | 110 | Letter Corresponding GL Type |
michael@0 | 111 | ------ --------------------- |
michael@0 | 112 | i64 int64ANGLE |
michael@0 | 113 | ui64 uint64ANGLE |
michael@0 | 114 | |
michael@0 | 115 | (Modify table 2.2, GL data types) Add two new types: |
michael@0 | 116 | |
michael@0 | 117 | GL Type Minimum Bit Width Description |
michael@0 | 118 | ------- ----------------- ----------------------------- |
michael@0 | 119 | int64ANGLE 64 Signed 2's complement integer |
michael@0 | 120 | uint64ANGLE 64 Unsigned binary integer |
michael@0 | 121 | |
michael@0 | 122 | Additions to Chapter 5 of the OpenGL ES 2.0 Specification (Special Functions) |
michael@0 | 123 | |
michael@0 | 124 | Add a new section 5.3 "Timer Queries": |
michael@0 | 125 | |
michael@0 | 126 | "5.3 Timer Queries |
michael@0 | 127 | |
michael@0 | 128 | Timer queries use query objects to track the amount of time needed to |
michael@0 | 129 | fully complete a set of GL commands, or to determine the current time |
michael@0 | 130 | of the GL. |
michael@0 | 131 | |
michael@0 | 132 | Timer queries are associated with query objects. The command |
michael@0 | 133 | |
michael@0 | 134 | void GenQueriesANGLE(sizei n, uint *ids); |
michael@0 | 135 | |
michael@0 | 136 | returns <n> previously unused query object names in <ids>. These |
michael@0 | 137 | names are marked as used, but no object is associated with them until |
michael@0 | 138 | the first time they are used by BeginQueryANGLE. Query objects contain |
michael@0 | 139 | one piece of state, an integer result value. This result value is |
michael@0 | 140 | initialized to zero when the object is created. Any positive integer |
michael@0 | 141 | except for zero (which is reserved for the GL) is a valid query |
michael@0 | 142 | object name. |
michael@0 | 143 | |
michael@0 | 144 | Query objects are deleted by calling |
michael@0 | 145 | |
michael@0 | 146 | void DeleteQueriesANGLE(sizei n, const uint *ids); |
michael@0 | 147 | |
michael@0 | 148 | <ids> contains <n> names of query objects to be deleted. After a |
michael@0 | 149 | query object is deleted, its name is again unused. Unused names in |
michael@0 | 150 | <ids> are silently ignored. |
michael@0 | 151 | If an active query object is deleted its name immediately becomes unused, |
michael@0 | 152 | but the underlying object is not deleted until it is no longer active. |
michael@0 | 153 | |
michael@0 | 154 | A timer query can be started and finished by calling |
michael@0 | 155 | |
michael@0 | 156 | void BeginQueryANGLE(enum target, uint id); |
michael@0 | 157 | void EndQueryANGLE(enum target); |
michael@0 | 158 | |
michael@0 | 159 | where <target> is TIME_ELAPSED_ANGLE. If BeginQueryANGLE is called |
michael@0 | 160 | with an unused <id>, that name is marked as used and associated with |
michael@0 | 161 | a new query object. |
michael@0 | 162 | |
michael@0 | 163 | If BeginQueryANGLE is called with an <id> of zero, if the active query |
michael@0 | 164 | object name for <target> is non-zero, if <id> is the name of an existing |
michael@0 | 165 | query object whose type does not match <target>, or if <id> is the active |
michael@0 | 166 | query object name for any query type, the error INVALID_OPERATION is |
michael@0 | 167 | generated. If EndQueryANGLE is called while no query with the same target |
michael@0 | 168 | is in progress, an INVALID_OPERATION error is generated. |
michael@0 | 169 | |
michael@0 | 170 | When BeginQueryANGLE and EndQueryANGLE are called with a <target> of |
michael@0 | 171 | TIME_ELAPSED_ANGLE, the GL prepares to start and stop the timer used for |
michael@0 | 172 | timer queries. The timer is started or stopped when the effects from all |
michael@0 | 173 | previous commands on the GL client and server state and the framebuffer |
michael@0 | 174 | have been fully realized. The BeginQueryANGLE and EndQueryANGLE commands |
michael@0 | 175 | may return before the timer is actually started or stopped. When the timer |
michael@0 | 176 | query timer is finally stopped, the elapsed time (in nanoseconds) is |
michael@0 | 177 | written to the corresponding query object as the query result value, and |
michael@0 | 178 | the query result for that object is marked as available. |
michael@0 | 179 | |
michael@0 | 180 | If the elapsed time overflows the number of bits, <n>, available to hold |
michael@0 | 181 | elapsed time, its value becomes undefined. It is recommended, but not |
michael@0 | 182 | required, that implementations handle this overflow case by saturating at |
michael@0 | 183 | 2^n - 1. |
michael@0 | 184 | |
michael@0 | 185 | The necessary state is a single bit indicating whether an timer |
michael@0 | 186 | query is active, the identifier of the currently active timer |
michael@0 | 187 | query, and a counter keeping track of the time that has passed. |
michael@0 | 188 | |
michael@0 | 189 | When the command |
michael@0 | 190 | |
michael@0 | 191 | void QueryCounterANGLE(uint id, enum target); |
michael@0 | 192 | |
michael@0 | 193 | is called with <target> TIMESTAMP_ANGLE, the GL records the current time |
michael@0 | 194 | into the corresponding query object. The time is recorded after all |
michael@0 | 195 | previous commands on the GL client and server state and the framebuffer |
michael@0 | 196 | have been fully realized. When the time is recorded, the query result for |
michael@0 | 197 | that object is marked available. QueryCounterANGLE timer queries can be |
michael@0 | 198 | used within a BeginQueryANGLE / EndQueryANGLE block where the <target> is |
michael@0 | 199 | TIME_ELAPSED_ANGLE and it does not affect the result of that query object. |
michael@0 | 200 | The error INVALID_OPERATION is generated if the <id> is already in use |
michael@0 | 201 | within a BeginQueryANGLE/EndQueryANGLE block." |
michael@0 | 202 | |
michael@0 | 203 | Additions to Chapter 6 of the OpenGL ES 2.0 Specification (State and State |
michael@0 | 204 | Requests) |
michael@0 | 205 | |
michael@0 | 206 | Add a new section 6.1.9 "Timer Queries": |
michael@0 | 207 | |
michael@0 | 208 | "The command |
michael@0 | 209 | |
michael@0 | 210 | boolean IsQueryANGLE(uint id); |
michael@0 | 211 | |
michael@0 | 212 | returns TRUE if <id> is the name of a query object. If <id> is zero, |
michael@0 | 213 | or if <id> is a non-zero value that is not the name of a query |
michael@0 | 214 | object, IsQueryANGLE returns FALSE. |
michael@0 | 215 | |
michael@0 | 216 | Information about a query target can be queried with the command |
michael@0 | 217 | |
michael@0 | 218 | void GetQueryivANGLE(enum target, enum pname, int *params); |
michael@0 | 219 | |
michael@0 | 220 | <target> identifies the query target and can be TIME_ELAPSED_ANGLE or |
michael@0 | 221 | TIMESTAMP_ANGLE for timer queries. |
michael@0 | 222 | |
michael@0 | 223 | If <pname> is CURRENT_QUERY_ANGLE, the name of the currently active query |
michael@0 | 224 | for <target>, or zero if no query is active, will be placed in <params>. |
michael@0 | 225 | |
michael@0 | 226 | If <pname> is QUERY_COUNTER_BITS_ANGLE, the implementation-dependent number |
michael@0 | 227 | of bits used to hold the query result for <target> will be placed in |
michael@0 | 228 | <params>. The number of query counter bits may be zero, in which case |
michael@0 | 229 | the counter contains no useful information. |
michael@0 | 230 | |
michael@0 | 231 | For timer queries (TIME_ELAPSED_ANGLE and TIMESTAMP_ANGLE), if the number |
michael@0 | 232 | of bits is non-zero, the minimum number of bits allowed is 30 which |
michael@0 | 233 | will allow at least 1 second of timing. |
michael@0 | 234 | |
michael@0 | 235 | The state of a query object can be queried with the commands |
michael@0 | 236 | |
michael@0 | 237 | void GetQueryObjectivANGLE(uint id, enum pname, int *params); |
michael@0 | 238 | void GetQueryObjectuivANGLE(uint id, enum pname, uint *params); |
michael@0 | 239 | void GetQueryObjecti64vANGLE(uint id, enum pname, int64 *params); |
michael@0 | 240 | void GetQueryObjectui64vANGLE(uint id, enum pname, uint64 *params); |
michael@0 | 241 | |
michael@0 | 242 | If <id> is not the name of a query object, or if the query object |
michael@0 | 243 | named by <id> is currently active, then an INVALID_OPERATION error is |
michael@0 | 244 | generated. |
michael@0 | 245 | |
michael@0 | 246 | If <pname> is QUERY_RESULT_ANGLE, then the query object's result |
michael@0 | 247 | value is returned as a single integer in <params>. If the value is so |
michael@0 | 248 | large in magnitude that it cannot be represented with the requested type, |
michael@0 | 249 | then the nearest value representable using the requested type is |
michael@0 | 250 | returned. If the number of query counter bits for target is zero, then |
michael@0 | 251 | the result is returned as a single integer with the value zero. |
michael@0 | 252 | |
michael@0 | 253 | There may be an indeterminate delay before the above query returns. If |
michael@0 | 254 | <pname> is QUERY_RESULT_AVAILABLE_ANGLE, FALSE is returned if such a delay |
michael@0 | 255 | would be required; otherwise TRUE is returned. It must always be true |
michael@0 | 256 | that if any query object returns a result available of TRUE, all queries |
michael@0 | 257 | of the same type issued prior to that query must also return TRUE. |
michael@0 | 258 | |
michael@0 | 259 | Querying the state for a given timer query forces that timer query to |
michael@0 | 260 | complete within a finite amount of time. |
michael@0 | 261 | |
michael@0 | 262 | If multiple queries are issued on the same target and id prior to |
michael@0 | 263 | calling GetQueryObject[u]i[64]vANGLE, the result returned will always be |
michael@0 | 264 | from the last query issued. The results from any queries before the |
michael@0 | 265 | last one will be lost if the results are not retrieved before starting |
michael@0 | 266 | a new query on the same <target> and <id>." |
michael@0 | 267 | |
michael@0 | 268 | Errors |
michael@0 | 269 | |
michael@0 | 270 | The error INVALID_VALUE is generated if GenQueriesANGLE is called where |
michael@0 | 271 | <n> is negative. |
michael@0 | 272 | |
michael@0 | 273 | The error INVALID_VALUE is generated if DeleteQueriesANGLE is called |
michael@0 | 274 | where <n> is negative. |
michael@0 | 275 | |
michael@0 | 276 | The error INVALID_OPERATION is generated if BeginQueryANGLE is called |
michael@0 | 277 | when a query of the given <target> is already active. |
michael@0 | 278 | |
michael@0 | 279 | The error INVALID_OPERATION is generated if EndQueryANGLE is called |
michael@0 | 280 | when a query of the given <target> is not active. |
michael@0 | 281 | |
michael@0 | 282 | The error INVALID_OPERATION is generated if BeginQueryANGLE is called |
michael@0 | 283 | where <id> is zero. |
michael@0 | 284 | |
michael@0 | 285 | The error INVALID_OPERATION is generated if BeginQueryANGLE is called |
michael@0 | 286 | where <id> is the name of a query currently in progress. |
michael@0 | 287 | |
michael@0 | 288 | The error INVALID_OPERATION is generated if BeginQueryANGLE is called |
michael@0 | 289 | where <id> is the name of an existing query object whose type does not |
michael@0 | 290 | match <target>. |
michael@0 | 291 | |
michael@0 | 292 | The error INVALID_ENUM is generated if BeginQueryANGLE or EndQueryANGLE |
michael@0 | 293 | is called where <target> is not TIME_ELAPSED_ANGLE. |
michael@0 | 294 | |
michael@0 | 295 | The error INVALID_ENUM is generated if GetQueryivANGLE is called where |
michael@0 | 296 | <target> is not TIME_ELAPSED_ANGLE or TIMESTAMP_ANGLE. |
michael@0 | 297 | |
michael@0 | 298 | The error INVALID_ENUM is generated if GetQueryivANGLE is called where |
michael@0 | 299 | <pname> is not QUERY_COUNTER_BITS_ANGLE or CURRENT_QUERY_ANGLE. |
michael@0 | 300 | |
michael@0 | 301 | The error INVALID_ENUM is generated if QueryCounterANGLE is called where |
michael@0 | 302 | <target> is not TIMESTAMP_ANGLE. |
michael@0 | 303 | |
michael@0 | 304 | The error INVALID_OPERATION is generated if QueryCounterANGLE is called |
michael@0 | 305 | on a query object that is already in use inside a |
michael@0 | 306 | BeginQueryANGLE/EndQueryANGLE. |
michael@0 | 307 | |
michael@0 | 308 | The error INVALID_OPERATION is generated if GetQueryObjectivANGLE, |
michael@0 | 309 | GetQueryObjectuivANGLE, GetQueryObjecti64vANGLE, or |
michael@0 | 310 | GetQueryObjectui64vANGLE is called where <id> is not the name of a query |
michael@0 | 311 | object. |
michael@0 | 312 | |
michael@0 | 313 | The error INVALID_OPERATION is generated if GetQueryObjectivANGLE, |
michael@0 | 314 | GetQueryObjectuivANGLE, GetQueryObjecti64vANGLE, or |
michael@0 | 315 | GetQueryObjectui64vANGLE is called where <id> is the name of a currently |
michael@0 | 316 | active query object. |
michael@0 | 317 | |
michael@0 | 318 | The error INVALID_ENUM is generated if GetQueryObjectivANGLE, |
michael@0 | 319 | GetQueryObjectuivANGLE, GetQueryObjecti64vANGLE, or |
michael@0 | 320 | GetQueryObjectui64vANGLE is called where <pname> is not |
michael@0 | 321 | QUERY_RESULT_ANGLE or QUERY_RESULT_AVAILABLE_ANGLE. |
michael@0 | 322 | |
michael@0 | 323 | New State |
michael@0 | 324 | |
michael@0 | 325 | (Add a new table 6.xx, "Query Operations") |
michael@0 | 326 | |
michael@0 | 327 | Get Value Type Get Command Initial Value Description Sec |
michael@0 | 328 | --------- ---- ----------- ------------- ----------- ------ |
michael@0 | 329 | - B - FALSE query active 5.3 |
michael@0 | 330 | CURRENT_QUERY_ANGLE Z+ GetQueryivANGLE 0 active query ID 5.3 |
michael@0 | 331 | QUERY_RESULT_ANGLE Z+ GetQueryObjectuivANGLE, 0 samples-passed count 5.3 |
michael@0 | 332 | GetQueryObjectui64vANGLE |
michael@0 | 333 | QUERY_RESULT_AVAILABLE_ANGLE B GetQueryObjectivANGLE FALSE query result available 5.3 |
michael@0 | 334 | |
michael@0 | 335 | New Implementation Dependent State |
michael@0 | 336 | |
michael@0 | 337 | (Add the following entry to table 6.18): |
michael@0 | 338 | |
michael@0 | 339 | Get Value Type Get Command Minimum Value Description Sec |
michael@0 | 340 | -------------------------- ---- ----------- ------------- ---------------- ------ |
michael@0 | 341 | QUERY_COUNTER_BITS_ANGLE Z+ GetQueryivANGLE see 6.1.9 Number of bits in 6.1.9 |
michael@0 | 342 | query counter |
michael@0 | 343 | |
michael@0 | 344 | Examples |
michael@0 | 345 | |
michael@0 | 346 | (1) Here is some rough sample code that demonstrates the intended usage |
michael@0 | 347 | of this extension. |
michael@0 | 348 | |
michael@0 | 349 | GLint queries[N]; |
michael@0 | 350 | GLint available = 0; |
michael@0 | 351 | // timer queries can contain more than 32 bits of data, so always |
michael@0 | 352 | // query them using the 64 bit types to avoid overflow |
michael@0 | 353 | GLuint64ANGLE timeElapsed = 0; |
michael@0 | 354 | |
michael@0 | 355 | // Create a query object. |
michael@0 | 356 | glGenQueriesANGLE(N, queries); |
michael@0 | 357 | |
michael@0 | 358 | // Start query 1 |
michael@0 | 359 | glBeginQueryANGLE(GL_TIME_ELAPSED_ANGLE, queries[0]); |
michael@0 | 360 | |
michael@0 | 361 | // Draw object 1 |
michael@0 | 362 | .... |
michael@0 | 363 | |
michael@0 | 364 | // End query 1 |
michael@0 | 365 | glEndQueryANGLE(GL_TIME_ELAPSED_ANGLE); |
michael@0 | 366 | |
michael@0 | 367 | ... |
michael@0 | 368 | |
michael@0 | 369 | // Start query N |
michael@0 | 370 | glBeginQueryANGLE(GL_TIME_ELAPSED_ANGLE, queries[N-1]); |
michael@0 | 371 | |
michael@0 | 372 | // Draw object N |
michael@0 | 373 | .... |
michael@0 | 374 | |
michael@0 | 375 | // End query N |
michael@0 | 376 | glEndQueryANGLE(GL_TIME_ELAPSED_ANGLE); |
michael@0 | 377 | |
michael@0 | 378 | // Wait for all results to become available |
michael@0 | 379 | while (!available) { |
michael@0 | 380 | glGetQueryObjectivANGLE(queries[N-1], GL_QUERY_RESULT_AVAILABLE_ANGLE, &available); |
michael@0 | 381 | } |
michael@0 | 382 | |
michael@0 | 383 | for (i = 0; i < N; i++) { |
michael@0 | 384 | // See how much time the rendering of object i took in nanoseconds. |
michael@0 | 385 | glGetQueryObjectui64vANGLE(queries[i], GL_QUERY_RESULT_ANGLE, &timeElapsed); |
michael@0 | 386 | |
michael@0 | 387 | // Do something useful with the time. Note that care should be |
michael@0 | 388 | // taken to use all significant bits of the result, not just the |
michael@0 | 389 | // least significant 32 bits. |
michael@0 | 390 | AdjustObjectLODBasedOnDrawTime(i, timeElapsed); |
michael@0 | 391 | } |
michael@0 | 392 | |
michael@0 | 393 | This example is sub-optimal in that it stalls at the end of every |
michael@0 | 394 | frame to wait for query results. Ideally, the collection of results |
michael@0 | 395 | would be delayed one frame to minimize the amount of time spent |
michael@0 | 396 | waiting for the GPU to finish rendering. |
michael@0 | 397 | |
michael@0 | 398 | (2) This example is basically the same as the example above but uses |
michael@0 | 399 | QueryCounter instead. |
michael@0 | 400 | |
michael@0 | 401 | GLint queries[N+1]; |
michael@0 | 402 | GLint available = 0; |
michael@0 | 403 | // timer queries can contain more than 32 bits of data, so always |
michael@0 | 404 | // query them using the 64 bit types to avoid overflow |
michael@0 | 405 | GLuint64ANGLE timeStart, timeEnd, timeElapsed = 0; |
michael@0 | 406 | |
michael@0 | 407 | // Create a query object. |
michael@0 | 408 | glGenQueriesANGLE(N+1, queries); |
michael@0 | 409 | |
michael@0 | 410 | // Query current timestamp 1 |
michael@0 | 411 | glQueryCounterANGLE(queries[0], GL_TIMESTAMP_ANGLE); |
michael@0 | 412 | |
michael@0 | 413 | // Draw object 1 |
michael@0 | 414 | .... |
michael@0 | 415 | |
michael@0 | 416 | // Query current timestamp N |
michael@0 | 417 | glQueryCounterANGLE(queries[N-1], GL_TIMESTAMP_ANGLE); |
michael@0 | 418 | |
michael@0 | 419 | // Draw object N |
michael@0 | 420 | .... |
michael@0 | 421 | |
michael@0 | 422 | // Query current timestamp N+1 |
michael@0 | 423 | glQueryCounterANGLE(queries[N], GL_TIMESTAMP_ANGLE); |
michael@0 | 424 | |
michael@0 | 425 | // Wait for all results to become available |
michael@0 | 426 | while (!available) { |
michael@0 | 427 | glGetQueryObjectivANGLE(queries[N], GL_QUERY_RESULT_AVAILABLE_ANGLE, &available); |
michael@0 | 428 | } |
michael@0 | 429 | |
michael@0 | 430 | for (i = 0; i < N; i++) { |
michael@0 | 431 | // See how much time the rendering of object i took in nanoseconds. |
michael@0 | 432 | glGetQueryObjectui64vANGLE(queries[i], GL_QUERY_RESULT_ANGLE, &timeStart); |
michael@0 | 433 | glGetQueryObjectui64vANGLE(queries[i+1], GL_QUERY_RESULT_ANGLE, &timeEnd); |
michael@0 | 434 | timeElapsed = timeEnd - timeStart; |
michael@0 | 435 | |
michael@0 | 436 | // Do something useful with the time. Note that care should be |
michael@0 | 437 | // taken to use all significant bits of the result, not just the |
michael@0 | 438 | // least significant 32 bits. |
michael@0 | 439 | AdjustObjectLODBasedOnDrawTime(i, timeElapsed); |
michael@0 | 440 | } |
michael@0 | 441 | |
michael@0 | 442 | Issues from EXT_timer_query |
michael@0 | 443 | |
michael@0 | 444 | (1) What time interval is being measured? |
michael@0 | 445 | |
michael@0 | 446 | RESOLVED: The timer starts when all commands prior to BeginQuery() have |
michael@0 | 447 | been fully executed. At that point, everything that should be drawn by |
michael@0 | 448 | those commands has been written to the framebuffer. The timer stops |
michael@0 | 449 | when all commands prior to EndQuery() have been fully executed. |
michael@0 | 450 | |
michael@0 | 451 | (2) What unit of time will time intervals be returned in? |
michael@0 | 452 | |
michael@0 | 453 | RESOLVED: Nanoseconds (10^-9 seconds). This unit of measurement allows |
michael@0 | 454 | for reasonably accurate timing of even small blocks of rendering |
michael@0 | 455 | commands. The granularity of the timer is implementation-dependent. A |
michael@0 | 456 | 32-bit query counter can express intervals of up to approximately 4 |
michael@0 | 457 | seconds. |
michael@0 | 458 | |
michael@0 | 459 | (3) What should be the minimum number of counter bits for timer queries? |
michael@0 | 460 | |
michael@0 | 461 | RESOLVED: 30 bits, which will allow timing sections that take up to 1 |
michael@0 | 462 | second to render. |
michael@0 | 463 | |
michael@0 | 464 | (4) How are counter results of more than 32 bits returned? |
michael@0 | 465 | |
michael@0 | 466 | RESOLVED: Via two new datatypes, int64ANGLE and uint64ANGLE, and their |
michael@0 | 467 | corresponding GetQueryObject entry points. These types hold integer |
michael@0 | 468 | values and have a minimum bit width of 64. |
michael@0 | 469 | |
michael@0 | 470 | (5) Should the extension measure total time elapsed between the full |
michael@0 | 471 | completion of the BeginQuery and EndQuery commands, or just time |
michael@0 | 472 | spent in the graphics library? |
michael@0 | 473 | |
michael@0 | 474 | RESOLVED: This extension will measure the total time elapsed between |
michael@0 | 475 | the full completion of these commands. Future extensions may implement |
michael@0 | 476 | a query to determine time elapsed at different stages of the graphics |
michael@0 | 477 | pipeline. |
michael@0 | 478 | |
michael@0 | 479 | (6) If multiple query types are supported, can multiple query types be |
michael@0 | 480 | active simultaneously? |
michael@0 | 481 | |
michael@0 | 482 | RESOLVED: Yes; an application may perform a timer query and another |
michael@0 | 483 | type of query simultaneously. An application can not perform multiple |
michael@0 | 484 | timer queries or multiple queries of other types simultaneously. An |
michael@0 | 485 | application also can not use the same query object for another query |
michael@0 | 486 | and a timer query simultaneously. |
michael@0 | 487 | |
michael@0 | 488 | (7) Do query objects have a query type permanently associated with them? |
michael@0 | 489 | |
michael@0 | 490 | RESOLVED: No. A single query object can be used to perform different |
michael@0 | 491 | types of queries, but not at the same time. |
michael@0 | 492 | |
michael@0 | 493 | Having a fixed type for each query object simplifies some aspects of the |
michael@0 | 494 | implementation -- not having to deal with queries with different result |
michael@0 | 495 | sizes, for example. It would also mean that BeginQuery() with a query |
michael@0 | 496 | object of the "wrong" type would result in an INVALID_OPERATION error. |
michael@0 | 497 | |
michael@0 | 498 | UPDATE: This resolution was relevant for EXT_timer_query and OpenGL 2.0. |
michael@0 | 499 | Since EXT_transform_feedback has since been incorporated into the core, |
michael@0 | 500 | the resolution is that BeginQuery will generate error INVALID_OPERATION |
michael@0 | 501 | if <id> represents a query object of a different type. |
michael@0 | 502 | |
michael@0 | 503 | (8) How predictable/repeatable are the results returned by the timer |
michael@0 | 504 | query? |
michael@0 | 505 | |
michael@0 | 506 | RESOLVED: In general, the amount of time needed to render the same |
michael@0 | 507 | primitives should be fairly constant. But there may be many other |
michael@0 | 508 | system issues (e.g., context switching on the CPU and GPU, virtual |
michael@0 | 509 | memory page faults, memory cache behavior on the CPU and GPU) that can |
michael@0 | 510 | cause times to vary wildly. |
michael@0 | 511 | |
michael@0 | 512 | Note that modern GPUs are generally highly pipelined, and may be |
michael@0 | 513 | processing different primitives in different pipeline stages |
michael@0 | 514 | simultaneously. In this extension, the timers start and stop when the |
michael@0 | 515 | BeginQuery/EndQuery commands reach the bottom of the rendering pipeline. |
michael@0 | 516 | What that means is that by the time the timer starts, the GL driver on |
michael@0 | 517 | the CPU may have started work on GL commands issued after BeginQuery, |
michael@0 | 518 | and the higher pipeline stages (e.g., vertex transformation) may have |
michael@0 | 519 | started as well. |
michael@0 | 520 | |
michael@0 | 521 | (9) What should the new 64 bit integer type be called? |
michael@0 | 522 | |
michael@0 | 523 | RESOLVED: The new types will be called GLint64ANGLE/GLuint64ANGLE. The new |
michael@0 | 524 | command suffixes will be i64 and ui64. These names clearly convey the |
michael@0 | 525 | minimum size of the types. These types are similar to the C99 standard |
michael@0 | 526 | type int_least64_t, but we use names similar to the C99 optional type |
michael@0 | 527 | int64_t for simplicity. |
michael@0 | 528 | |
michael@0 | 529 | Issues from ARB_timer_query |
michael@0 | 530 | |
michael@0 | 531 | (10) What about tile-based implementations? The effects of a command are |
michael@0 | 532 | not complete until the frame is completely rendered. Timing recorded |
michael@0 | 533 | before the frame is complete may not be what developers expect. Also |
michael@0 | 534 | the amount of time needed to render the same primitives is not |
michael@0 | 535 | consistent, which conflicts with issue (8) above. The time depends on |
michael@0 | 536 | how early or late in the scene it is placed. |
michael@0 | 537 | |
michael@0 | 538 | RESOLVED: The current language supports tile-based rendering okay as it |
michael@0 | 539 | is written. Developers are warned that using timers on tile-based |
michael@0 | 540 | implementation may not produce results they expect since rendering is not |
michael@0 | 541 | done in a linear order. Timing results are calculated when the frame is |
michael@0 | 542 | completed and may depend on how early or late in the scene it is placed. |
michael@0 | 543 | |
michael@0 | 544 | (11) Can the GL implementation use different clocks to implement the |
michael@0 | 545 | TIME_ELAPSED and TIMESTAMP queries? |
michael@0 | 546 | |
michael@0 | 547 | RESOLVED: Yes, the implemenation can use different internal clocks to |
michael@0 | 548 | implement TIME_ELAPSED and TIMESTAMP. If different clocks are |
michael@0 | 549 | used it is possible there is a slight discrepancy when comparing queries |
michael@0 | 550 | made from TIME_ELAPSED and TIMESTAMP; they may have slight |
michael@0 | 551 | differences when both are used to measure the same sequence. However, this |
michael@0 | 552 | is unlikely to affect real applications since comparing the two queries is |
michael@0 | 553 | not expected to be useful. |
michael@0 | 554 | |
michael@0 | 555 | Issues |
michael@0 | 556 | |
michael@0 | 557 | (12) What should we call this extension? |
michael@0 | 558 | |
michael@0 | 559 | RESOLVED: ANGLE_timer_query |
michael@0 | 560 | |
michael@0 | 561 | (13) Why is this done as a separate extension instead of just supporting |
michael@0 | 562 | ARB_timer_query? |
michael@0 | 563 | |
michael@0 | 564 | ARB_timer_query is written against OpenGL 3.2, which includes a lot of |
michael@0 | 565 | the required support for dealing with query objects. None of these |
michael@0 | 566 | functions or tokens exist in OpenGL ES, and as such have to be added in |
michael@0 | 567 | this specification. |
michael@0 | 568 | |
michael@0 | 569 | (14) How does this extension differ from ARB_timer_query? |
michael@0 | 570 | |
michael@0 | 571 | This extension contains most ARB_timer_query behavior unchanged as well |
michael@0 | 572 | as a subset of the query support required to use it from the core |
michael@0 | 573 | OpenGL 3.2 spec. It omits the glGetInteger(TIMESTAMP) functionality used to |
michael@0 | 574 | query the current time on the GPU, but the behavior for all remaining |
michael@0 | 575 | functionality taken from ARB_timer_query is the same. |
michael@0 | 576 | |
michael@0 | 577 | (15) Are query objects shareable between multiple contexts? |
michael@0 | 578 | |
michael@0 | 579 | RESOLVED: No. Query objects are lightweight and we normally share |
michael@0 | 580 | large data across contexts. Also, being able to share query objects |
michael@0 | 581 | across contexts is not particularly useful. In order to do the async |
michael@0 | 582 | query across contexts, a query on one context would have to be finished |
michael@0 | 583 | before the other context could query it. |
michael@0 | 584 | |
michael@0 | 585 | Revision History |
michael@0 | 586 | |
michael@0 | 587 | Revision 1, 2011/04/28 |
michael@0 | 588 | - copied from revision 9 of ARB_timer_query and revision 7 of |
michael@0 | 589 | ARB_occlusion_query |
michael@0 | 590 | - removed language that was clearly not relevant to ES2 |
michael@0 | 591 | - rebased changes against the OpenGL ES 2.0 specification |