[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

Florian Bösch [email protected]
Mon Mar 9 13:57:17 PDT 2015


The undefined behavior is what happens if:

   1. You do a draw on that buffer region
   2. You read it back

Both of these activities can be captured by the WebGL implementation and
appropriately dealt with (by for instance issuing a GL_ERROR). There's no
principal obstacle to converting this undefined behavior to a defined one.

On Mon, Mar 9, 2015 at 6:01 PM, Zhenyao Mo <[email protected]> wrote:

> 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
> same.
>
> >
> >>
> >> >> 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/20150309/923805e8/attachment.html>


More information about the public_webgl mailing list