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

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



Even without INVALID bit, for WRITE case, you still save one copying
for in-process WebGL implementations.

On Mon, Mar 16, 2015 at 11:20 AM, 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
-----------------------------------------------------------