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

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

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

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