[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

Florian Bösch [email protected]
Fri Mar 6 22:47:19 PST 2015


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?


> >> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150307/310097a1/attachment.html>


More information about the public_webgl mailing list