-
Notifications
You must be signed in to change notification settings - Fork 637
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
shader_debugprintf: support new VVL-DEBUG-PRINTF message and fix VVL version check for API selection #1187
base: main
Are you sure you want to change the base?
Conversation
…version check for API selection
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much for this PR. I do have some remarks though, mostly related to comment and code structure. I think it's important that people can easily follow understand the changes ;)
Thanks @SaschaWillems for the feedback. I am away on vacation this week, but will make the requested changes when I am back. UPDATE: Back now and changes submitted in 0dc4963. |
No idea why, but with this PR and the latest SDK (1.3.296) and in windows, this sample is now again running with less than 1 fps. Forcing it to use VK 1.2 is somehow even slower (0 or inf fps). If I force VK 1.0 performance is fine, but I don't get any debug output. Not sure what is happening here and why this sample is so problematic. The debug printf sample from m own samples repo works just fine no matter the api version :/ |
Very strange. Can I ask you to recheck before and after this PR, but being careful with your SDK version selection and project gen/build? I did a lot of testing with old and new SDKs on Windows 10, Linux and macOS before submitting originally. I will go back and test again to see if I can somehow duplicate what you are seeing.
Debug PrintF requires Vulkan 1.1 or later. So no surprise that you are not getting debug output with API 1.0.
I suspect your repo's sample relies on the instrinsic Debug PrintF capability at the shader level on Windows. However, this is not cross-platform portable. Whereas the Vulkan-Samples one uses the VVL version of the feature all the time. Perhaps that is why you are seeing a difference at least on Windows. Again, I will so back and see if I can verify this. |
It also happens with the old code (before this PR). I only have SDK 1.3.296 installed. So probably a regression in the validation layers? |
Ok, I have rechecked this PR on Windows 10, and even fast-forwarded my local branch to current main HEAD just to make sure. I am using Vulkan SDK 1.3.296.0 with my Radeon RX6600XT GPU. My Vulkan Configurator has been reset to default settings. Is it possible that your Vulkan Configurator has a custom setting that is interfering with the sample? Or possibly a difference between AMD and nVidia GPUs? Just grasping at straws since I cannot duplicate your issue and the 1.3.296 VVL seems to be working correctly using API 1.1 for debug printf. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this change, I have to distinguish two cases:
- VulkanConfigurator is running
VK_EXT_LAYER_SETTINGS_EXTENSION_NAME is available
instance creation is done by VulkanSample::create_instance (line 469)
render speed is high
debug_utils_message_callback is never called, thus no debugprintf output - VulkanConfigurator is not running
VK_EXT_LAYER_SETTINGS_EXTENSION_NAME is not available
instance creation is done locally (line 523)
render speed is extremely low
debug_utils_message_callback is called, with higher rate than the frame rate
Note, in case 2, you're using VkValidationFeaturesEXT
, which is part of VK_EXT_VALIDATION_FEATURES_EXTENSION_NAME
. But you don't ask for it in the ShaderDebugPrintf
constructor (or anywhere else). And in fact, that extension is not supported on my machine. Strange, that the VVL doesn't cry there.
That would explain why it's so slow for me. I never ran that sample with the VulkanConfigurator running. That's case 2. |
…ons to ShaderDebugPrintf::create_instance()
Thanks @asuessenbach for pointing out the missing
These changes may not be the final solution as I have observed the following when testing:
In summary:
Lastly, I thought |
…ing instance creation
…e::[HPP]Instance()
Ok, I think I have finally figured it out. It appears that you don't need to actually enable the
|
AFAIK, those two extensions ( Besides that, just to make sure it has been noted: As |
Description
Fixes two issues that arose with Vulkan SDK 1.3.296:
VVL-DEBUG-PRINTF
callback message. Previous SDKs usedWARNING-DEBUG-PRINTF
orUNKNOWN-DEBUG-PRINTF
. Without this fix the debug data is not available in the UI Overlay.Fixes #1184.
Tested on Windows 10, Manjaro Linux, and macOS Ventura using Vulkan SDKs 1.3.290 and 1.3.296.
I hope this is the last time I have to fix this. It seems that VVL changes can easily break this sample.
General Checklist:
Please ensure the following points are checked:
Note: The Samples CI runs a number of checks including:
If this PR contains framework changes:
batch
command line argument to make sure all samples still work properlySample Checklist
If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist: