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

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



On Tue, Mar 17, 2015 at 9:58 PM, Zhenyao Mo <zmo@chromium.org> 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
implementations.
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.