People won't write spinners for timing. The will write spinners for occlusion queries.Since it's the same API, the only difference is the enums passed in, it's important we don't expose the wrong API now and be stuck with an unsupportable or massively abused API in the future.On Fri, Apr 12, 2013 at 1:54 PM, Florian Bösch <firstname.lastname@example.org> wrote:
On Fri, Apr 12, 2013 at 10:42 PM, Rémi Arnaud <email@example.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:
- lots of timers
- now work with all preceding queriesBecause 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.