[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

Florian Bösch [email protected]
Wed Mar 11 22:48:09 PDT 2015


I'm assuming you refer to the condition in mapBufferRange where two
overlapping ranges are created with the unsynchronized bit, which the spec
states as undefined. This is also easy to solve, just don't let people
create overlapping mapped buffer ranges (another gl error).

On Thu, Mar 12, 2015 at 5:12 AM, Jeff Gilbert <[email protected]> wrote:

> 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 <[email protected]> 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 <[email protected]> wrote:
>>
>>> On Fri, Mar 6, 2015 at 10:47 PM, Florian Bösch <[email protected]> wrote:
>>> > On Sat, Mar 7, 2015 at 12:14 AM, Zhenyao Mo <[email protected]> wrote:
>>> >>
>>> >> On Fri, Mar 6, 2015 at 2:13 PM, Florian Bösch <[email protected]>
>>> wrote:
>>> >> > On Fri, Mar 6, 2015 at 10:55 PM, Zhenyao Mo <[email protected]>
>>> 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.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150312/b762dc54/attachment.html>


More information about the public_webgl mailing list