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

Re: [Public WebGL] Queries in WebGL 2.0



Well, sort of. We still allow pipeline stalls with this entrypoint,
just not within a single JS 'frame'.

Also the spec doesn't detail how a not-yet-available request fails. I
suppose I can add this.

On Thu, Apr 21, 2016 at 6:17 PM, Kenneth Russell <kbr@google.com> wrote:
> 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
>>> -----------------------------------------------------------
>>>
>>
>

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