The undefined behavior is what happens if:
- You do a draw on that buffer region
- You read it backBoth 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 <email@example.com> wrote:On Fri, Mar 6, 2015 at 10:47 PM, Florian Bösch <firstname.lastname@example.org> wrote:
> On Sat, Mar 7, 2015 at 12:14 AM, Zhenyao Mo <email@example.com> wrote:
>> On Fri, Mar 6, 2015 at 2:13 PM, Florian Bösch <firstname.lastname@example.org> wrote:
>> > On Fri, Mar 6, 2015 at 10:55 PM, Zhenyao Mo <email@example.com> 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
> 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.