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

Re: [Public WebGL] For review: ANGLE_timer_query extension



Thanks for those use cases.

The proposed API is no different than the 'existing' API, except that it groups several queries into a set, wait for the last query of the set to be available before using a callback. Getting the values from a query is not different than before. 

So once could do the following:
Querytimer()
timerData[nbqueries++].name = "some data"

// Then in the callback
for (var i=0; i<results.lengh(); i++)  
timerData[I].value=queryValue(I);


This way one can easily associate any data, in any data structure of its like, and the value of the timer.

Regards
-- Remi


From: Florian Bösch <pyalot@gmail.com>
Date: Friday, April 12, 2013 2:45 PM
To: Rémi Arnaud <remi.arnaud@amd.com>
Cc: Rémi Arnaud <jsremi@gmail.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

Timer queries measure the time it takes the GPU to run a set of commands. It does this by setting a server state.

Since the list of commands issued stands in relation to what the application did to generate them, the timers stand in relation to the application code.

The simplest usecase is simply measuring the entire execution time. This requires one query per frame. You will probably not need more than 2-3 queries in total since it's exceedingly unlikely that a query 2 frames back would not have been filled trough 2 flips. But that might depend on how the browser handles buffering and flips.

The next more interesting usecase is a list of checkpoints. That is useful for coarse measurement of the stages of what your application goes trough. Though even so, you would mark each "stage" in some way you can read it out back later easely, for instance stick it into a list as in foo[x].query = thequery; foo[x].name = 'somecheckpoint'. So that you can display the list of checkpoints in a UI or somesuch.

The next more interesting usecase would be to capture the call stack of checkpoints. For instance let a stacklevel be defined as a begin/end. Then let the methods be defined as:

var someMethod = function(){
  stackBegin(query, 'Somename');
  stackEnd();
}

Quite like the console performance measurement API really.

So what you can later do is display a realtime UI of the frame stack which you can expand and collapse and show the timings as the application runs. Which would provide you with a lot of insight over the performance characteristic of your rendering, also it'd be cool.


On Fri, Apr 12, 2013 at 11:33 PM, Arnaud, Remi <Remi.Arnaud@amd.com> wrote:
Rater than using a bunch of superlatives such as 'utter nonsense' and 'useless', could you please explain better the use case?

What has capturing a call stack has anything to do with performance timers? Why is allowing the programmer to group a set of queries into one array of results through a callback any limitation? 

But I guess the main issue is that there is no consensus of what are the issues to be solved for this API to be useful. So until this is resolved, there is no point having a discussion about API design.

Regards
-- Remi

From: Florian Bösch <pyalot@gmail.com>
Date: Friday, April 12, 2013 11:12 AM
To: Rémi Arnaud <remi.arnaud@amd.com>
Cc: Rémi Arnaud <jsremi@gmail.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 8:06 PM, Arnaud, Remi <Remi.Arnaud@amd.com> wrote:
The programmer knows exactly what queries calls where done in order, the 'results' provide the queries in the same order. There is no need to extra semantic
That's utter nonesense. You didn't think this trough. A so inclined programmer might capture a call stack of his drawing. Where's your "known order" now? Nowhere. It's gone. It had structure before you mangled it into a flat list. A flat list is not the only usecase of queries. Stop dictating application structure to people wanting to use timer queries. Think trough what people might want to do with them before assuming "A list is what anybody will ever need".