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

Re: [Public WebGL] For review: ANGLE_timer_query extension



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

-- Remi

From: Florian Bösch <pyalot@gmail.com>
Date: Friday, April 12, 2013 11:01 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 7:41 PM, Arnaud, Remi <Remi.Arnaud@amd.com> wrote:
Not at all. The main difference is that the user cannot ask for a query before they are available.
Users won't be asking for results before they're available because that's a stupid behavior. The whole spinloop of death debate is strawman. You can abuse any API. Stop inventing problems. Spinloop of death is 1) stupid 2) you won't do it because it'll kill your performance 3) the API doesn't encourage it either way 4) the documentation doesn't encourage. 
 
User can only access the 'results' from the parameter passed into the callback.
Which is useless because obtaining a query and sticking it somewhere gives it meaning to the application code. A flat list of gunk doesn't have any meaning anymore, therefore useless.
 
I don't understand how the proposed API takes control away from the user to individually address a query, it actually provide a way to group queries. User can query any number of timers in the callback and save this in whatever data structure it want.
It takes control away because it hides the queries.
 
 Ok, still the proposed API avoid the need to user to do 1000s of allocation, 1000s of garbage collection. I thought this would be of interest in the concept of a real time (1000s times per frame) use.
You have not read my examples. You also have not read Bens answer to my question on the reusability of queries. You won't need to allocate them every frame. Some people might want to use pools. Others might want to use their own data structures to put them in. Stop inventing a semantic that makes this impossible.


The proposed API does exactly the same, except that the queries are grouped and available as a (whatever you want to be) array, list…. They are individually addressed in the callback, the user can put the result it whatever data structure it want….
It does not. You're just dumping a flat list on a user without any semantic meaning of where a query was used. That's useless.
 
 Sure, there can be hundreds of sets. The proposed API enable grouping the queries in sets, provides callback (event) when a given set if available, avoid pooling issue as mentioned in this email thread
Sets are useless.