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

Re: [Public WebGL] Queries in WebGL 2.0



WebGL deliberately changes the semantics of queries' results to prevent client code from stalling the pipeline. Code needs to be adjusted to anticipate that queries' results will not be made available in the current frame, but instead in subsequent frames. This was a deliberate design decision that Gregg helped inform. Tests have been written for it and adjusted for the difference in behavior compared to ES 3.0. See https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.23 for more details.

-Ken


On Thu, Apr 21, 2016 at 1:24 PM, Florian Bösch <pyalot@gmail.com> wrote:
Generating a pipeline-stall to wait for a query is actually valid code. For instance, the result of an occlusion query would be quite useless a few frames later.

On Thu, Apr 21, 2016 at 10:03 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:

kgilbert is absolutely correct, and this is how all specs are written to date.

We actually need to add language to our specs to detail what happens
when the query is not allowed to be available yet. Presumably this is
INVALID_OP, but it's not currently detailed. Rules-as-written,
same-frame QUERY_RESULT queries would spin the browser forever. :)

On Thu, Apr 21, 2016 at 10:19 AM,  <kgilbert@mozilla.com> wrote:
> On OpenGL ES, checking if the query result is available is optional, and only needed to determine if getting the query result will cause a pipeline stall.  In some cases, you have no choice but to stall the pipeline because without the query information, you can not correctly render the next frame.
>
> Is this intended to differ in WebGL?
>
> Cheers,
>   - Kearwood "Kip" Gilbert
>
>> On Apr 21, 2016, at 9:23 AM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
>>
>>
>> This is akin to using a framebuffer without checking if it's complete.
>> I don't think we should handhold this at the spec level.
>>
>> I think it could be useful to add a browser pref to add a (longer)
>> delay to query availability.
>>
>>> On Thu, Apr 21, 2016 at 8:15 AM, Kirill Dmitrenko <dmikis@yandex-team.ru> wrote:
>>>
>>> I think using ES6 Promise would be most reliable way to stop people using aforementioned snippet:
>>>
>>> gl.getQueryParameter(query, gl.QUERY_RESULT).then((result) => /* ... */);
>>>
>>> But it may be too big of a change and, if I understand correctly, can introduce some problems with coming WebAssembly.
>>>
>>> 21.04.2016, 15:31, "Gregg Tavares" <khronos@greggman.com>:
>>>> I didn't follow any public discussion of this feature but ... I'm already seeing people posting bad code which will just keep propagating forever
>>>>
>>>> Example from SO
>>>>
>>>> var query = gl.createQuery(); gl.beginQuery(gl.ANY_SAMPLES_PASSED, query); // ... draw a small quad at the specified 3d position ... gl.endQuery(gl.ANY_SAMPLES_PASSED); // some time later, typically a few frames later (after a fraction of a second) gl.getQueryParameter(query, gl.QUERY_RESULT);
>>>>
>>>> Shouldn't the spec require correct behavior? Basically you have to call
>>>>
>>>>     gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE)
>>>>
>>>> and it has to return true or
>>>>
>>>>     gl.getQueryParameter(query, gl.QUERY_RESULT);
>>>>
>>>> should generate INVALID_OPERATION
>>>>
>>>> I suppose that doesn't really fix the issue because people can just put
>>>>
>>>>     gl.getQueryParameter(query, gl.QUERY_RESULT_AVAILABLE)   // ignore result and pray
>>>>     gl.getQueryParameter(query, gl.QUERY_RESULT)
>>>>
>>>> If WebGL 2 is supposed to be an API that works everywhere shouldn't the API at least try to help people not write code that won't actually work everywhere?
>>>
>>>
>>> --
>>> Kirill Dmitrenko
>>> Yandex Maps Team
>>>
>>> -----------------------------------------------------------
>>> 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
>>> -----------------------------------------------------------
>>
>> -----------------------------------------------------------
>> 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
>> -----------------------------------------------------------
>>

-----------------------------------------------------------
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
-----------------------------------------------------------