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

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



On Sat, Mar 7, 2015 at 12:14 AM, Zhenyao Mo <zmo@chromium.org> wrote:
On Fri, Mar 6, 2015 at 2:13 PM, Florian Bösch <pyalot@gmail.com> wrote:
> On Fri, Mar 6, 2015 at 10:55 PM, Zhenyao Mo <zmo@chromium.org> wrote:
>>
>> 1) We can't expose INVALIDATE_BUFFER bit
>
> Please elaborate.

Undefined buffer values.
Yes, but why is that a problem?
 
>> 2) We can't expose FLUSH bit with mapping implementations (we can only
>> allow it in copying implementations), therefore also not
>> glFlushMappedBufferRange() for mapping implementations.
>
> Please elaborate.

Again, undefined buffer values between write and flush (if you forget to flush)
Again, why is that a problem?
 
In copying implementations, we can hold on any writes until flush
time, so if you use the buffer between writes and flush, you get the
old data; but not for mapping implementations.
mapBuffer[Range] do not make guarantees about when the data is transferred. The only guarantees are that mapBuffer[Range] will not block and that if it isn't transferred by the time you call unmapBuffer, it gets flushed. What/how the browser handles that in the background isn't going to break those guarantees. And it could be argued that by running a copying thread that shuffles stuff on the IPC while JS continues to execute you can emulate that behavior rather well.

This mapBuffer problem is really an IPC problem. The details of the implementation may differ (virtual memory manager vs. copying thread), but the problem is the same. The semantic offered by the GL API to tackle this problem is fairly reasonable, and if you where to offer non blocking transfers to JS to shuffle stuff to the GPU process, it's a reasonable model to do so. I don't see the issue in using that model to actually offer that capability. And some implementations won't have to come up with a copying thread, because they don't use threads, or different processes at all.