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

Re: [Public WebGL] Specifying the behavior of bindXXX when passed a deleted resource



On Tue, Jun 18, 2013 at 4:23 PM, Gregg Tavares <gman@google.com> wrote:
>
>
>
> On Tue, Jun 18, 2013 at 3:58 PM, Zhenyao Mo <zmo@chromium.org> wrote:
>>
>> I vote for following closely to the GL behaviors, i.e.,
>>
>> 1) bind a texture/render_buffer/buffer that's deleted will generate an
>> error, the object becomes invalid as soon as delete* is called.
>
>
> But it's not GL behavior. Current GL behavior is quirky.
>
>    GLuint id = 123;
>    glBindTexture(GL_TEXTURE_2D, id);  // make a texture with name 123
>    glBindFramebuffer(GL_FRAMEBUFFER, fb);
>    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
> GL_TEXTURE_2D, id, 0);
>    glBindFramebuffer(GL_FRAMEBUFFER, 0);
>    glDeleteTexture(1, &id);  // the texture is now marked for deletion but
> it is not deleted
>
>    // ask what texture is on the framebuffer
>    glBindFramebuffer(GL_FRAMEBUFFER, fb);
>    GLint v;
>    glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER,
> GL_COLOR_ATTACHMENT0, GL_FRAMEBUFFER_ATTACHMENT_OBJECT_NAME, &v);
>    printf ("%d\n", v);  // prints 123
>
>    // so bind that texture.
>    glBindTexture(GL_TEXTURE_2D, v);  // this creates a new texture.
>
> There's now 2 textures with id 123. One you can bind, one you can't
>
> What I'm suggesting is that textures in WebGL should work like programs.
>
>    var tex = gl.createTexture();
>    gl.bindTexture(gl.TEXTURE_2D, tex);
>    gl.bindFramebuffer(gl.FRAMEBUFFER, fb);
>    gl.framebufferTexture2D(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT0,
> gl.TEXTURE_2D, id, 0);
>    gl.bindFramebuffer(gl.FRAMEBUFFER, null);
>    gl.deleteTexture(tex);  // the texture is now marked for deletion but it
> is not deleted
>
>    // ask what texture is on the framebuffer
>    gl.bindFramebuffer(gl.FRAMEBUFFER, fb);
>    var attachment = gl.getFramebufferAttachmentParameter(gl.FRAMEBUFFER,
> gl.COLOR_ATTACHMENT0, gl.FRAMEBUFFER_ATTACHMENT_OBJECT_NAME);
>
>    assert(attachment == tex);
>
>    // so bind that texture.
>    gl.bindTexture(GL_TEXTURE_2D, tex);
>
> safe, even though the texture has been marked as deleted since all
> references were never released it's still safe to bind it.
> It would only go away when the last reference went away so if you followed
> all that with
>
>    gl.deleteFramebuffer(fb);  // loses the reference on the framebuffer
>    gl.bindTexture(GL_TEXTURE_2D, null);  // loses the reference on the
> context we just added 2 lines up
>
> The texture is now deleted.
>
>    gl.bindTexture(GL_TEXTURE_2D, tex);  // INVALID_VALUE, texture has been
> deleted.
>
> Which is exactly how programs work.

Apologies for the late reply, in particular since Gregg may not be
receiving this email.

I've added an action item for the working group to revisit this topic.
Upon further thought, defining resource deletion to be more lazy may
be the best decision for performance reasons.

If WebGL's deletion behavior is defined as being more eager than
OpenGL's, a significant amount of validation will have to be done for
container objects like framebuffers and programs each time they're
used. For example, a framebuffer might have to be considered
invalidated if an attached texture had been deleted. (The WebGL
implementation wouldn't be able to delete the object under the hood,
but would have to treat it as though it had been deleted.) There are
other considerations. For example, OpenGL defines different behavior
if a shader attached to a program is deleted, comparing when the
program is currently bound and when it isn't.

I don't believe this issue is a major problem for application
developers, and am concerned that a poor decision may significantly
impact compatibility and performance, so plan to defer work on this
for the moment.

-Ken



>>
>>
>> 2) useProgram / attachShader and other queries are still valid when
>> deleteProgram / deleteShader is called but they haven't been truly
>> deleted yet.
>>
>> Mo
>>
>> On Tue, Jun 18, 2013 at 3:45 PM, Gregg Tavares <gman@google.com> wrote:
>> > So the GL group says you can continue to use call useProgram on a
>> > program
>> > marked for deletion but that has not actually been deleted yet. Once it
>> > has
>> > actually been deleted you'll get an error
>> >
>> > Should we do the same for all resources in WebGL?
>> >
>> >
>> >
>> > On Tue, Jun 18, 2013 at 12:14 PM, Gregg Tavares <gman@google.com> wrote:
>> >>
>> >> Actually I'm not sure what should happen here and AFAICT it's not clear
>> >> from the ES spec.
>> >>
>> >> The ES spec doesn't say what happens if you call useProgram on a
>> >> program
>> >> marked for deletion but not actually deleted but it is clear you can
>> >> still
>> >> use the object for things like GetProgramiv as that's how you query if
>> >> it's
>> >> marked for deletion.
>> >>
>> >> If they decided to make other resources behave like shaders and
>> >> programs
>> >> (ie, you must call glGenXXX to create an id and glBindXXX stops
>> >> creating
>> >> resources and delete behaves the same), then there's all kinds of
>> >> interesting questions
>> >>
>> >> If you can useProgram a program marked for deletion but not deleted
>> >> then
>> >> you should be able to bindTexture a texture marked for deletion but not
>> >> deleted.
>> >> Similarly you should be able to call getTexParameter on a texture
>> >> marked
>> >> for deletion just like you can call getProgramParameter on a program
>> >> marked
>> >> for deletion
>> >> Other queries and binds would also seem to work.
>> >>
>> >> I don't think that would be a problem. In that case bindXXX and
>> >> useProgram
>> >> would only fail on objects actually deleted, not objects just marked
>> >> for
>> >> deletion. I know Chrome would have no problem with that as we already
>> >> don't
>> >> actually call glDeleteXXX on anything unless all its references are
>> >> gone
>> >> since there are driver bugs otherwise. I'm pretty sure Firefox does the
>> >> same.
>> >>
>> >> I've asked for some input from the OpenGL WG.
>> >>
>> >>
>> >>
>> >> On Mon, Jun 17, 2013 at 10:16 AM, Zhenyao Mo <zmo@chromium.org> wrote:
>> >>>
>> >>> Yes and yes.
>> >>>
>> >>> But for gl.userProgram, we need to be more careful to define the
>> >>> "deleted" state, because the name is still valid after
>> >>> gl.deleteProgram if it's currently bound.
>> >>>
>> >>> Mo
>> >>>
>> >>> On Fri, Jun 14, 2013 at 3:33 PM, Gregg Tavares <gman@google.com>
>> >>> wrote:
>> >>> > AFAICT the WebGL spec is currently silent on what happens when you
>> >>> > bind
>> >>> > a
>> >>> > deleted resource.
>> >>> >
>> >>> > In other words
>> >>> >
>> >>> >     var tex = gl.createTexture();
>> >>> >     gl.deleteTexture(tex);
>> >>> >     gl.bindTexture(gl.TEXTURE_2D, tex);  // What does this do?
>> >>> >
>> >>> > The conformance tests expect that to bind 0
>> >>> > [glBindTexture(gl.TEXTURE_2D,
>> >>> > 0)] but the WebGL spec doesn't say that's what's supposed to happen.
>> >>> >
>> >>> > We need to update the spec but I'm also curious if we should change
>> >>> > the
>> >>> > behavior. Should that bind above generate INVALID_VALUE or should it
>> >>> > stay as
>> >>> > is and bind 0?
>> >>> >
>> >>> > The same is true of gl.useProgram. Calling useProgram on a deleted
>> >>> > program
>> >>> > ends up calling glUseProgram(0) but that's not in the spec. In fact
>> >>> > it's
>> >>> > specifically against the spec as the ES 2.0.25 spec, 2.10.1 says
>> >>> >
>> >>> > Commands that accept shader or program object names will generate
>> >>> > the
>> >>> > error
>> >>> > INVALID_VALUE if the provided name is not the name of either a
>> >>> > shader
>> >>> > or
>> >>> > program object and INVALID_OPERATION  if the provided name identiļ¬es
>> >>> > an
>> >>> > object that is not the expected type.
>> >>> >
>> >>> >
>> >>> > We either need to fix implementations and tests to match the ES spec
>> >>> > or
>> >>> > update the WebGL spec to document the different behavior.
>> >>> >
>> >>> > Should binding a deleted resource generate an error? My vote = yes.
>> >>> > Should useProgram follow the ES spec and generate an error? My vote
>> >>> > =
>> >>> > yes
>> >>> >
>> >>> > Thoughts?
>> >>> >
>> >>> >
>> >>
>> >>
>> >
>
>

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