search

KhronosGroup / OpenXR-CTS

Conformance test suite for OpenXR
https://www.khronos.org/conformance/adopters/
Apache License 2.0
66 stars 21 forks source link

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

Open Ralith opened 2 years ago

Ralith commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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.

Ralith commented 1 year ago

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.