[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] For review: ANGLE_timer_query extension



JS can't call back inbetween executing JS or interrupt JS execution. The result would be an undefined interpreter state. A callback can only happen either immediately, or after all JS has finished running.


On Fri, Apr 12, 2013 at 11:13 PM, Rémi Arnaud <jsremi@gmail.com> wrote:
I'm lost.
I don't see any connection between the question and the answer.

All was asked is the ability to get result from a query in the middle of a frame, without habing to wait for the last query to be available. Therfore, in the 'current' API, first poling a query and in the same frame later, poling a another timer.
With the proposed API, creating 2 sets of queries, and having 2 callbacks.

So just to restate here's some pseudo code

querytimer()
.. gl calls
querytimer(A)
.. gl calls
+ Callback/polling for timer(A) and prev
.. Potentially do something about timerA in this same frame
querytimer(B)
...gl calls
querytimer(C)
...
glfinish()
+ callback/polling from last timer


The example above show that more than one poll per frame can be useful, in particular if any reaction to the result is expected to happen in the same frame


Regards
- Remi

From: Florian Bösch <pyalot@gmail.com>
Date: Fri, 12 Apr 2013 22:54:16 +0200
To: Rémi Arnaud<jsremi@gmail.com>
Cc: Rémi Arnaud<remi.arnaud@amd.com>; Ben Vanik<benvanik@google.com>; owner-public_webgl@khronos.org<owner-public_webgl@khronos.org>; Kenneth Russell<kbr@google.com>; Gregg Tavares<gman@google.com>; Public Webgl<public_webgl@khronos.org>; Brian Cornell<bcornell@google.com>; Glenn Maynard<glenn@zewt.org>
Subject: Re: [Public WebGL] For review: ANGLE_timer_query extension

On Fri, Apr 12, 2013 at 10:42 PM, Rémi Arnaud <jsremi@gmail.com> wrote:
This said I see no reason why someone could not decide to read first a query result that was in the middle of the frame, and then one at the end of the frame. For example in a multipass algorithm
It's a bad idea to do it, and I don't know either why Greg and others make such a fuss about it, it's not like people would write deadspinners for that.

So obviously you can't get the timing results for the remainder of the frame from the last synchronizing command (such as gl.finish).

But I don't see a reason why anybody shouldn't be able to use the queries before the last synchronizing command (and without polling). For example:

  1. lots of timers
  2. gl.finish()
  3. now work with all preceding queries
Because by the time gl.finish() returns it is guaranteed that all preceding timer queries are ready and filled.

Regardless of this fussy non-problem, you shouldn't do that for a couple reasons:

1) You need to call gl.finish() which synchronizes and slows everything down.
2) A single frame measurement as a deciding factor for a following rendering logic is just gonna make the code flap in the wind since execution times contain a fair deal of variance.

But if you really really want to do that, I don't think we should dictate that people can't.