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

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



From my previous investigation here, it looked like we should be able to be safe exposing this with the exception of the UNSYNCHRONIZED bit. I'll take another look.

On Mon, Mar 9, 2015 at 1:57 PM, Florian Bösch <pyalot@gmail.com> wrote:
The undefined behavior is what happens if:
  1. You do a draw on that buffer region
  2. You read it back
Both of these activities can be captured by the WebGL implementation and appropriately dealt with (by for instance issuing a GL_ERROR). There's no principal obstacle to converting this undefined behavior to a defined one.

On Mon, Mar 9, 2015 at 6:01 PM, Zhenyao Mo <zmo@chromium.org> wrote:
On Fri, Mar 6, 2015 at 10:47 PM, Florian Bösch <pyalot@gmail.com> wrote:
> 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?

Because when the spec says the values are undefined, who knows what
some "crazy" drivers may do.  There is nothing preventing them from
leaking data from other contexts / users. WebGL removed all (all that
I am aware of) undefined behaviors in ES2.  WebGL 2 needs to do the
same.

>
>>
>> >> 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.