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

Vulkan-compatible implementations should pass Vulkan validation layer checks #35

Open
Ralith opened this issue Feb 23, 2022 · 3 comments
Labels
enhancement New feature or request synced to gitlab Synced to internal Khronos gitlab

Comments

@Ralith
Copy link

Ralith commented Feb 23, 2022

e.g. SteamVR generates numerous validation layers on startup and more every frame, causing undefined behavior and making it difficult to distinguish genuine application bugs. This could be mechanically validated by configuring a Vulkan debug messenger, running through a few frames (if not the entire test suite), and failing the test if when an error is reported to the callback. The Vulkan validation layers should be configured for maximum strictness (e.g. synchronization validation, GPU-assisted).

@rpavlik-bot rpavlik-bot added the synced to gitlab Synced to internal Khronos gitlab label Feb 23, 2022
@rpavlik-bot
Copy link
Collaborator

An issue (number 1667) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#1667 ), to facilitate working group processes.

This GitHub issue will continue to be the main site of discussion.

@rpavlik
Copy link
Contributor

rpavlik commented Dec 8, 2022

This would be nice, however, I'm not sure it's practical at least in the short term: VR compositors have to exercise code paths that are not super commonly used, so between driver bugs/workarounds and validation layer bugs, there tend to be Vulkan validation errors to ignore.

(There is code that would do this, that is partially guarded to only build in debug mode, and partially commented out. I recently touched it when trying to debug validation issues in the CTS itself.)

I do agree we should work toward this, though, if nothing else, to make app developers' lives easier.

@rpavlik rpavlik added the enhancement New feature or request label Dec 8, 2022
@Ralith
Copy link
Author

Ralith commented Dec 9, 2022

Thanks. My data isn't representative, but the reports I've received from Rust binding users suggest that workarounds involving illegal Vulkan are running unconditionally, which is not ideal. If there are known issues in specific drivers, those could be excluded from a CTS validation requirement while still accomplishing the main goal.

Publicly documenting known issues would be a big help as well. This would help application developers tell what to ignore with confidence, allow new issues to be identified, and help ensure that driver and validation layer bugs can actually get resolved. Most of the OpenXR runtime error spam I see has been around for years longer than typical validation layer bugfix turnaround, for example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request synced to gitlab Synced to internal Khronos gitlab
Projects
None yet
Development

No branches or pull requests

3 participants