[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange
Tue Mar 17 14:28:02 PDT 2015
On Tue, Mar 17, 2015 at 9:58 PM, Zhenyao Mo <[email protected]> wrote:
> I am aware of this alternative, but that's not currently supported by
> js. Basically you return a writable buffer to js by MapBufferRange.
> Now you need to keep track of which part are dirty and which are
> clean. I am not saying it's impossible, but requires new semantics
> and optimization.
> I don't see this can be better than BufferSubData in out-of-process
mapBufferRange isn't a magic performance enhancer. It's hardly any faster
at all when used as a bufferSubData substitute. You cannot magic away the
fact that a memcpy needs to transfer bits out of client memory into vram,
and that this transfer takes time, because you don't have infinite
bandwidth and planck time latency. Treating mapBufferRange as a replacement
of bufferSubData isn't how this works. That's not what it's for.
The only corner case of where you will be able to ecke out significantly
more performance has to do with asynchronous ring-buffer updates. That is,
for streaming data in. In this case, you can use the mapping API in a
fashion as to avoid synchronization for dependent draws.
I've measured naive uses of bufferSubData vs. mapBuffer vs. persistent
mapBuffer vs. persistent unsynchronized mapBuffer vs. etc. The differences
are not life changing.
So when you're saying "oh but performance will not be better than
bufferSubData", congratulations, if your implementation does that, it's
already pretty good. It could get a little better if you get the
unsynchronized double-buffered dependent-draw avoiding explicit flush case
right as well. But we're not talking life-changing performance difference
here. It's a nice little boost, particularly for specific usecases such as
video and vertex streaming.
> There are many other examples that we have to hold back features that
> developers would love, for example, certain compressed texture formats
> not supported on iOS, etc. It may seem frustrating but in the long
> run, good for WebGL as a web standard.
There aren't many examples of that. In fact, in WebGL 1.0, there are none
that I can think of on the top of my head. And in WebGL 2.0, there is one
(TEXTURE_SWIZZLE) which is excluded for a pretty good reason (it's actually
impossible to implement in D3D).
There are extensions (and compression formats are extension), and we have a
lot of discussions about these.
But cutting out a whole swathe of APIs out of a core GL specification,
that's quite a step. Quite a step indeed.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl