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

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

On Mar 18, 2015, at 7:16 PM, Florian Bösch <pyalot@gmail.com> wrote:

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.


>> 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’s for MAP_INVALIDATE_*. I was talking just about MAP_UNSYNCHRONIZED_BIT. I missed the INVAL buried in the middle of the text I quoted.



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail