Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please be more explicit about "all such related state" #264

Open
tsuoranta opened this issue Apr 15, 2019 · 3 comments
Open

Please be more explicit about "all such related state" #264

tsuoranta opened this issue Apr 15, 2019 · 3 comments
Assignees

Comments

@tsuoranta
Copy link
Contributor

@tsuoranta tsuoranta commented Apr 15, 2019

GL 4.6 core / GLES 3.2 section 5.1.2 has language:

"When a buffer ... object is successfully deleted, it is unbound from any bind points it is bound to in the current context, and detached from any attachments of container objects that are bound to the current context, as described for DeleteBuffers ... . If the object binding was established with other related state ... all such related state are restored to default values by the automatic unbind."

It would be great if there was more explicit language for what is included in "all such related state" for each object type / binding point. For example, the specification as is only indirectly suggests that enable/disable and divisor is not part of state that should be reset for vertex attrib pointers. It would also be great to list the side effects in object deletion API function.

@pdaniell-nv

This comment has been minimized.

Copy link
Contributor

@pdaniell-nv pdaniell-nv commented Apr 17, 2019

I believe the "other related state" depends on the type of buffer being deleted. For example, if it was bound to a GL_UNIFORM_BUFFER binding point then the "other related state" can be found in the Uniform Buffer Binding State table, which includes GL_UNIFORM_BUFFER_START and GL_UNIFORM_BUFFER_SIZE. Does that seem reasonable?

There probably is some room for improvement in the spec to be more explicit about the state that's getting restored to default values. We're definitely open to suggestions if you have an idea for improvement.

@tsuoranta

This comment has been minimized.

Copy link
Contributor Author

@tsuoranta tsuoranta commented Apr 24, 2019

My issue is with glVertexAttribPointer*(). It touches size, stride, type, normalized, pointer, buffer_binding, integer for vertex attrib array in VAO. I peeked (very quickly only) in mesa sources and it reset some but not all of these to defaults on auto-unbind. I suspect different drivers/vendors might do different things. This would be a potential problem when trying to cache GL state, at least in GLES where some apps still use client side data. Explicitly listing state to reset on auto-unbind would also make it clear which state is not reset. In case of VAO vertex attrib pointer state, divisor and enabled state is not.

@pdaniell-nv

This comment has been minimized.

Copy link
Contributor

@pdaniell-nv pdaniell-nv commented May 7, 2019

Would you be willing to propose spec edits to resolve this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.