[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

Florian Bösch [email protected]
Wed Mar 18 03:16:02 PDT 2015


On Wed, Mar 18, 2015 at 11:00 AM, Mark Callow <[email protected]> wrote:

>
> I’ll limit my comments to the following for now...
>
> > On Mar 18, 2015, at 7:12 AM, Zhenyao Mo <[email protected]> wrote:
> >
> >> With UNSYNCHRONIZED, MapBufferRange can be 'sharper', but potentially
> more
> >> performant:
> >> READ|UNSYNC: Still synchronous, but lets the GL process use
> UNSYNCHRONIZED
> >> to prevent stalls.
>
> READ | UNSYNC raises an INVALID_OPERATION error.
>
> >> WRITE|INVAL|UNSYNC: Still async, but lets the GL process use
> UNSYNCHRONIZED
> >> to prevent stalls.
> >
> > I don't think we can allow UNSYNCHRONIZED bit to reach the underlying
> > GL. That's leads to undefined behavior.
>
> The undefined behavior is whether a dereference in the GL (e.g. a draw
> operation) will see the pre-map buffer content or what the app has just
> written. I think this level of undefined behavior can be tolerated for the
> performance gain. There is no data leakage or other security issue with
> this undefined behavior.
>

Actually you cannot allow this undefined behavior, because the
specification states that:

 No GL error is generated if sub- sequent GL operations access unwritten
> data, but the result is *undefined* and *system errors* (possibly
> including *program termination*) may occur.


That doesn't mean you cannot expose WRITE|INVAL|UNSYNC, however it does
mean you need to prevent draw on invalid ranges (and convert that undefined
behavior to an error).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150318/b7329861/attachment.html>


More information about the public_webgl mailing list