[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

Florian Bösch [email protected]
Mon Mar 16 14:20:41 PDT 2015


The INVALIDATE flags don't influence pointer behavior. In any case that you
have established a mapping, you get a pointer returned that you can write
to. I don't see any benefit to the INVALIDATE flags, are there any? (they
just specify that the GPU can discard the previous contents of the
range/buffer except what has been written subsequently).

On Mon, Mar 16, 2015 at 7:20 PM, Zhenyao Mo <[email protected]> wrote:

> The efficient use cases that I see is: you map with INVALID* bit, so
> you just get a pointer you can write to.  This saves you the extra
> copying between CPU memory (js array) to vram, comparing with
> bufferSubData. Unfortunately that benefit is no longer there for
> non-in-process WebGL implementations.
>
> Unless there is a way to map a vram pointer to other processes on all
> platforms.
>
> On Mon, Mar 16, 2015 at 11:11 AM, Florian Bösch <[email protected]> wrote:
> > Even on native platforms mapBuffer[Range] isn't more efficient than
> > bufferSubData. Instead of blocking on the buffer[Sub]Data call, it just
> > blocks on the memcpy. If you set the asynchronous flag, it won't block,
> but
> > it'll still block on unmap and/or flush, which isn't more efficient than
> > buffer[Sub]Data. The only case where mapBuffer[Range] is faster is if
> you're
> > doing asynchronous ping-poned doubled buffered updates and issue no other
> > blocking command to the driver. Desktop GL has more options, but ES 3
> does
> > not.
> >
> > On Mon, Mar 16, 2015 at 7:07 PM, Zhenyao Mo <[email protected]> wrote:
> >>
> >> Oh I failed to type the keyword "efficiently".  My bad.
> >>
> >> On Mon, Mar 16, 2015 at 10:55 AM, Florian Bösch <[email protected]>
> wrote:
> >> > On Mon, Mar 16, 2015 at 6:03 PM, Zhenyao Mo <[email protected]> wrote:
> >> >>
> >> >> If it comes to a vote, I will vote "no" for introducing something to
> >> >> the core APIs that intrinsically cannot be implemented on
> >> >> non-in-process WebGL implementations.
> >> >
> >> > What exactly isn't implementable about it?
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150316/2b29b20f/attachment.html>


More information about the public_webgl mailing list