[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

Zhenyao Mo [email protected]
Mon Mar 16 15:47:53 PDT 2015


No, when I wrote the text, I was thinking about the benefit if it's
implemented in non-in-process webgl implementations.  In such
implementations, INVALIDATE flag means you don't have to read out the
content of the buffer before writing to it, so it makes some
significant perf gain.  For in-process WebGL implementations, it's
more of a burden, that you have to initialize the entire returned
buffer range to avoid undefined values, unless it can be guaranteed
the entire buffer range will be written into.

On Mon, Mar 16, 2015 at 2:20 PM, Florian Bösch <[email protected]> wrote:
> 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?
>> >
>> >
>
>

-----------------------------------------------------------
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