[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

Zhenyao Mo [email protected]
Mon Mar 9 10:01:04 PDT 2015

On Fri, Mar 6, 2015 at 10:47 PM, Florian Bösch <[email protected]> wrote:
> On Sat, Mar 7, 2015 at 12:14 AM, Zhenyao Mo <[email protected]> wrote:
>> On Fri, Mar 6, 2015 at 2:13 PM, Florian Bösch <[email protected]> wrote:
>> > On Fri, Mar 6, 2015 at 10:55 PM, Zhenyao Mo <[email protected]> wrote:
>> >>
>> >> 1) We can't expose INVALIDATE_BUFFER bit
>> >
>> > Please elaborate.
>> Undefined buffer values.
> Yes, but why is that a problem?

Because when the spec says the values are undefined, who knows what
some "crazy" drivers may do.  There is nothing preventing them from
leaking data from other contexts / users. WebGL removed all (all that
I am aware of) undefined behaviors in ES2.  WebGL 2 needs to do the

>> >> 2) We can't expose FLUSH bit with mapping implementations (we can only
>> >> allow it in copying implementations), therefore also not
>> >> glFlushMappedBufferRange() for mapping implementations.
>> >
>> > Please elaborate.
>> Again, undefined buffer values between write and flush (if you forget to
>> flush)
> Again, why is that a problem?
>> In copying implementations, we can hold on any writes until flush
>> time, so if you use the buffer between writes and flush, you get the
>> old data; but not for mapping implementations.
> mapBuffer[Range] do not make guarantees about when the data is transferred.
> The only guarantees are that mapBuffer[Range] will not block and that if it
> isn't transferred by the time you call unmapBuffer, it gets flushed.
> What/how the browser handles that in the background isn't going to break
> those guarantees. And it could be argued that by running a copying thread
> that shuffles stuff on the IPC while JS continues to execute you can emulate
> that behavior rather well.
> This mapBuffer problem is really an IPC problem. The details of the
> implementation may differ (virtual memory manager vs. copying thread), but
> the problem is the same. The semantic offered by the GL API to tackle this
> problem is fairly reasonable, and if you where to offer non blocking
> transfers to JS to shuffle stuff to the GPU process, it's a reasonable model
> to do so. I don't see the issue in using that model to actually offer that
> capability. And some implementations won't have to come up with a copying
> thread, because they don't use threads, or different processes at all.

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list