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

Re: [Public WebGL] WebGL2 and no mapBuffer/mapBufferRange



On Wed, Mar 18, 2015 at 11:00 AM, Mark Callow <khronos@callow.im> wrote:

I’ll limit my comments to the following for now...

> On Mar 18, 2015, at 7:12 AM, Zhenyao Mo <zmo@chromium.org> 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).