[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebGL2 and no mapBuffer/mapBufferRange



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 <pyalot@gmail.com> 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 <zmo@chromium.org> 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 <pyalot@gmail.com> 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 <zmo@chromium.org> wrote:
>> >>
>> >> Oh I failed to type the keyword "efficiently".  My bad.
>> >>
>> >> On Mon, Mar 16, 2015 at 10:55 AM, Florian Bösch <pyalot@gmail.com>
>> >> wrote:
>> >> > On Mon, Mar 16, 2015 at 6:03 PM, Zhenyao Mo <zmo@chromium.org> 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 public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------