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

KHR_parallel_shader_compile must define behavior under context loss #263

Open
kenrussell opened this issue Apr 11, 2019 · 2 comments
Open
Assignees

Comments

@kenrussell
Copy link
Member

In a discussion on Khronos' public_webgl mailing list about promoting WebGL's wrapper for the KHR_parallel_shader_compile extension, a point was raised:
https://www.khronos.org/webgl/public-mailing-list/public_webgl/1904/msg00004.php

Namely, the KHR_robustness specification defines that if a graphics reset occurs, then queries of certain global and per-object state signal that they completed, so that applications which might poll those values continuously don't go into an infinite loop:
https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_robustness.txt

(see the paragraph starting with "Any commands which might cause a polling application to block indefinitely...")

Currently, the KHR_parallel_shader_compile extension doesn't explicitly define what happens to pending compiles and links if a graphics reset occurs:
https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_parallel_shader_compile.txt

It should be updated to define that queries of GL_COMPLETION_STATUS_KHR for both shaders and programs will return GL_TRUE if a graphics reset occurs.

cc @vonture

@vonture
Copy link

vonture commented Apr 12, 2019

Filed http://anglebug.com/3379

@pdaniell-nv
Copy link
Contributor

We touched on this during the OpenGL/ES joint working group meeting today and agree this would be a good improvement to the GL_KHR_parallel_shader_compile spec. Will you propose a PR? Thanks.

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

No branches or pull requests

4 participants
@kenrussell @vonture @pdaniell-nv and others