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

Re: [Public WebGL] Resolving OES_vertex_array_object issues



Looks good. Merged. Thanks to you and Gregg for clarifying the needed behavior.

-Ken


On Mon, Sep 24, 2012 at 12:40 PM, Brandon Jones <bajones@google.com> wrote:
> As there's been no dissenting feedback on this matter I feel like it's
> reasonable to update the extension to require reference counting of attached
> buffers.
>
> Here's my pull request: https://github.com/KhronosGroup/WebGL/pull/36
>
>
> On Thu, Sep 6, 2012 at 1:02 PM, Gregg Tavares (社用) <gman@google.com> wrote:
>>
>> I should point out that for WebGL this means that most implementations
>> will need to not call glDeleteBuffer when the user calls webgl.deleteBuffer
>> but instead wait for all references to be released before calling
>> glDeleteBuffer. Otherwise, according to the ES 2.0 spec
>>
>>>    "... attempting to use a deleted buffer ...
>>> produces undefined results, including but not limited to possible GL
>>> errors and
>>> rendering corruption"
>>
>>
>> ES 3.0 fixes this problem and requires buffers to be reference counted and
>> usable past deletion just like other GL resources.
>>
>> Chrome already does this
>> WebKit does not yet (yea, I know Chrome is built on WebKit but in Chrome
>> we run our own GL)
>> I haven't checked Firefox
>>
>> -g
>>
>>
>>
>> On Thu, Sep 6, 2012 at 11:15 AM, Brandon Jones <bajones@google.com> wrote:
>>>
>>> I'm currently working on exposing the OES_vertex_array_object extension
>>> to Chrome, building on the work Ben Vanik did in Webkit. There is still an
>>> outstanding issue listed on the extension that should be resolved first,
>>> however.
>>>
>>> Quoting from the spec:
>>>
>>> The OES_vertex_array_object spec does not make it clear what happens to
>>> buffers that are deleted when they are referenced by vertex array objects.
>>> It is inferred that all buffers are reference counted.
>>>
>>> Before OES_vertex_array_object there was no way to use a deleted buffer
>>> in a single context as the spec states it would be unbound from all bind
>>> points. After OES_vertex_array_object it is now possible to use deleted
>>> buffers.
>>>
>>> Furthermore, the OpenGL ES 2.0 spec specifies that using a deleted buffer
>>> has undefined results including possibly corrupt rendering and generating GL
>>> errors. Undefined behavior is unacceptable for WebGL.
>>>
>>> As implied by the above text, it seems as if the natural resolution is to
>>> require that buffers be reference counted so that a buffer that has been
>>> referenced by a VAO will not be removed even after DeleteBuffer has been
>>> called, though further attempts to bind to that buffer directly should fail.
>>> In my opinion this feels like the most straightforward solution.
>>>
>>> Gregg Tavares pointed out to me that under this model the buffers should
>>> behave consistently with textures that are deleted while bound to a
>>> framebuffer:
>>>
>>> pg. 114 section 4.4.3
>>>
>>>>> If a texture object is deleted while its image is attached to the
>>>>> currently bound
>>>>>
>>>>> framebuffer, then it is as if FramebufferTexture2D had been called,
>>>>> with a texture
>>>>>
>>>>> of 0, for each attachment point to which this image was attached in the
>>>>> currently
>>>>>
>>>>> bound framebuffer. In other words, this texture image is first detached
>>>>> from all
>>>>>
>>>>> attachment points in the currently bound framebuffer. Note that the
>>>>> texture image is
>>>>>
>>>>> specifically not detached from any other framebuffer objects. Detaching
>>>>> the texture
>>>>>
>>>>> image from any other framebuffer objects is the responsibility of the
>>>>> application.
>>>
>>>
>>> Which would mean that deleted buffers would be dereferenced if they are
>>> referenced by the currently bound VAO (including the default VAO) but not
>>> from any other VAOs.
>>>
>>> The alternative is to immediately delete the buffers and generate an
>>> error when the user attempts to draw with a VAO that references a deleted
>>> buffer.
>>>
>>> Is there any reason why we should prefer immediate deletion to a
>>> reference counting model? Either way it would be nice to resolve the issue
>>> in the spec so that we can make this extension available everywhere.
>>>
>>> --Brandon Jones
>>
>>
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------