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

Re: [Public WebGL] For review: ANGLE_timer_query extension






On Tue, Apr 2, 2013 at 6:16 PM, Ben Vanik <benvanik@google.com> wrote:
Callbacks aren't really scalable for this kind of use.

Put up some code maybe to show this? It's certainly not obvious.
 
They create too much overhead when trying to sample times.

Don't agree.
 
They also break a lot of the usage patterns that make this API easy to use. I believe we've had this discussion before with respect to resource locks and I still stand by my assertions there: callbacks hurt performance, lead to spaghetti code (especially when it comes to trying to time hundreds+ things across frames/contexts),

Would have to see code to believe this.
 
and make the API less useful vs. the native version. Translating code that uses the API (via emscripten/etc) would also become much more difficult as the behavior is no longer the same.

That's not a valid reason to introduce bad APIs to _javascript_.
 

Callbacks also don't handle a potential use case of this (which may never happen in a browser such as Chrome but would in Firefox/etc) where you want to query and check the value in a single frame. ex, start drawing and begin a query, draw, then try to get the query result in the same tick to decide what to do next.

You shouldn't be doing that as have you no guarantee when the commands will happen. This isn't a use case we encourage. In fact it's one we should actively discourage since it's not remotely portable.
 
Of course, advanced applications will try to pipeline this across frames, but sometimes you can't (due to potential latency issues/etc).

I'm not sure I see a problem with that loop - you can shoot yourself in the foot many ways with code like that, and nobody should be writing that.

So don't make it possible.
 
But taking the sledgehammer approach of changing the API and breaking valid scenarios hurts those who have a real use of the API. People writing bad code will continue to find ways to do so.

That doesn't mean we should let them if it's trivial to prevent. Or maybe we should go make xhr, images, keys, etc all polling because because good programmers will do the right thing and bad will still write bad. 
 
If it was a must that it not be allowed, breaking the contract here and forcing all query results be set in a separate JS tick would prevent spin loops while retaining the polling API. It'd turn loops like that into while(true);, which is probably fine. As I said, I doubt with the latency imposed by the separate GPU process as in Chrome that any results will be coming back in the same tick anyway.

The API you're exposing is the same API used for occlusion queries in ES 3.0 and so whatever solution is chosen here will likely need to be the same for occlusion queries.

IMO that should be callbacks. That's the _javascript_ way. It's also browser friendly.  Polling is not.
 



On Tue, Apr 2, 2013 at 5:54 PM, Gregg Tavares <gman@google.com> wrote:
I've been told my by multiple people that APIs that can be used to spinwait are bad for _javascript_ and the browser in general.

The problem is people will do this

   beqinQuery();
   ...
   endQuery();

   // Spin Wait, blocking the browser and all UI processing  
   while (!getQueryParameter(RESULT_AVAILABLE));

It seems like queries should be based on callbacks.




On Tue, Apr 2, 2013 at 5:19 PM, Ben Vanik <benvanik@google.com> wrote:
The two APIs provide two different values -- glQueryCounter gives you a timestamp where glBeginQuery/glEndQuery give you a time elapsed. There are scenarios where both are interesting: if you're trying to get many elapsed times (such as timing draw calls/etc) then using the begin/end methods halves the number of query objects you need vs. trying to do it yourself via queryCounter. There's also the potential for the values retrieved from either to be different: the spec allows for different internal timing mechanisms to be used for both. I'm not sure if this is the case in reality, but it is allowed.




On Tue, Apr 2, 2013 at 5:03 PM, Kenneth Russell <kbr@google.com> wrote:
Good question. As the primary author of the ANGLE_timer_query
extension, Ben Vanik should answer it.

Note that beginQuery and endQuery will definitely be needed in the
OpenGL ES 3.0 upgrade, since they support occlusion and primitive
queries.

-Ken


On Tue, Apr 2, 2013 at 4:51 PM, Arnaud, Remi <Remi.Arnaud@amd.com> wrote:
> I was wondering if beginQueryANGLE and endQueryANGLE are needed, seems
> like queryCounterANGLE alone can cover all use cases?
>
> Regards
> -- Remi
>
> On 4/2/13 4:33 PM, "Kenneth Russell" <kbr@google.com> wrote:
>
>>
>>The MapsGL team has requested for some time that the ANGLE_timer_query
>>extension be exposed to WebGL. The primary use case is to allow tools
>>to be written which identify performance problems in WebGL
>>applications.
>>
>>Please review the proposal and send comments to the list:
>>
>>http://www.khronos.org/registry/webgl/extensions/proposals/ANGLE_timer_que
>>ry/
>>
>>Note that the planned upgrade of WebGL to the OpenGL ES 3.0 API will
>>pull the query functions into the core. This extension becomes much
>>smaller when applied to that API version.
>>
>>Thanks,
>>
>>-Ken
>>
>>-----------------------------------------------------------
>>You are currently subscribed to public_webgl@khronos.org.
>>To unsubscribe, send an email to majordomo@khronos.org with
>>the following command in the body of your email:
>>unsubscribe public_webgl
>>-----------------------------------------------------------
>>
>>
>
>