[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] For review: ANGLE_timer_query extension
You don't use one per frame - you use many. That's what the simple examples don't show.
A typical frame in a complex scene has many nested drawing batches - like for each pass for each depth mode for each shader for each texture for each buffer etc. You put timers around those things - sometimes 100+. Since you'll want to support high latency you'll want a couple sets of these timers. For the application we're building there may be 1000+ timers in flight at any given time.
Just as you pipeline readback from framebuffers/etc so that you aren't blocking the GPU, you schedule your timer readback the same way -- on frame N you are checking to see if the timers from frame N-1 or N-2 are available yet. And using clever querying you can quickly check all of them -- for example if the results of the last timer from frame N-1 is available then you know all the timers from frame N-2 are available too -- no need to check them.
When it comes to getting the values out it varies what you actually want to get. For performance testing you may query all timers every frame. For runtime testing deployed to real user machines most frames you may only query the outermost timer - if it says the frame took <10ms or draw (or some other threshold) you can just ignore the rest. But if it did take >Nms you can start searching down the timer tree to find what took the time. A simple binary search can then tell you exactly what kind of operation was slow for that user and allow you to report that back to a diagnostics service, change rendering quality, or even switch rendering engines to ensure the user has the best experience.