shader_debugprintf: Use API 1.2 for SDKs <= 1.3.290, API 1.1 for SDKs > 1.3.290

[SRSaunders]

Description

This fixes the _shaderdebugprintf sample to work correctly with Vulkan SDKs >= 1.3.290 where the Validation Layer requires Vulkan API >= 1.1 to enable the debugPrintfEXTfeature. Earlier SDKs with older Validation Layers did not enforce this and could run with Vulkan API 1.0. This change also respects the upcoming Validation Layer performance fix for issue 7562 which caused slowdowns on SDKs <= 1.3.290 when using the debugPrintfEXT feature with the correct APi 1.1 version. VVL fix 8323 will be available in Vulkan SDKs > 1.3.290 and thus Vulkan API 1.1 can be used by this sample for these future SDKs without performance problems.

UPDATE: This PR also contains a workaround for SDKs not yet containing the VVL performance fix above. For SDKs <= 1.3.290, this sample will now use Vulkan API 1.2 which does not exhibit the performance problem, and also satisfies the debugPrintfEXT layer feature which requires Vulkan API level >= 1.1 to function.

Tested on macOS Ventura using: a) Vulkan SDKs 1.3.283 and 1.3.290 with their stock Validation Layers, and b) using a private build of the most recent Validation Layer containing the fix above.

Fixes #1132

General Checklist:

Please ensure the following points are checked:

• [x] My code follows the coding style
• [x] I have reviewed file licenses
• [x] I have commented any added functions (in line with Doxygen)
• [x] I have commented any code that could be hard to understand
• [x] My changes do not add any new compiler warnings
• [x] My changes do not add any new validation layer errors or warnings
• [x] I have used existing framework/helper functions where possible
• [x] My changes do not add any regressions
• [ ] I have tested every sample to ensure everything runs correctly. Not applicable.

• [x] This PR describes the scope and expected impact of the changes I am making

  Note: The Samples CI runs a number of checks including:

  • [x] I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
  • [x] My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions

  If this PR contains framework changes:

  • [ ] I did a full batch run using the batch command line argument to make sure all samples still work properly

Sample Checklist

If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist:

• [x] I have tested the sample on at least one compliant Vulkan implementation
• [ ] If the sample is vendor-specific, I have tagged it appropriately
• [x] I have stated on what implementation the sample has been tested so that others can test on different implementations and platforms
• [ ] Any dependent assets have been merged and published in downstream modules
• [ ] For new samples, I have added a paragraph with a summary to the appropriate chapter in the readme of the folder that the sample belongs to e.g. api samples readme
• [ ] For new samples, I have added a tutorial README.md file to guide users through what they need to know to implement code using this feature. For example, see conditional_rendering
• [ ] For new samples, I have added a link to the Antora navigation so that the sample will be listed at the Vulkan documentation site

[SaschaWillems]

Doesn't work for me. The sample now seems to be completely broken in any case :(

• With VK_API_VERSION_1_0: Good framerate, but no output of vertex positions visible
• With VK_API_VERSION_1_1: Unusable framerate (less than 1 fps), but output of vertex positions visible

Tested with SDK 1.3.290.

Pinging @spencer-lunarg

[spencer-lunarg]

https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/8323 should have fixed this, I'll pull down this change and test on the various things today to see what is going on

[SRSaunders]

https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/8323 is not included in SDK 1.3.290, and will only fix the performance issue in future SDKs when it is included.

@SaschaWillems that is why I asked if you wanted me to put in a workaround in _shaderdebugprintf for previous SDKs. You answered no, so that is why this PR reverts to API 1.1 for all previous and current SDKs, and is the reason for the performance issue with SDKs <= 290. My workaround was to use Vulkan API 1.2 for previous SDKs <= 290, and API 1.1 for SDKs > 290. This would avoid performance issues for SDKs that don't have the above fix.

Please advise if you want this workaround added here.

Note that API 1.0 was always the wrong choice, since it should never have worked, and only worked for SDKs < 290 by chance. Even though 290 does not include the performance fix, it adds a check for debugPrintfEXT to be at least API 1.1. So that is why my workaround proposes using API 1.2 for SDKs up to and including 290, and API 1.1 for all future SDKs.

Perhaps it would be easier if I just add the workaround in an additional commit here, and you both can review.

[SaschaWillems]

This fixes the shader_debugprintf sample to work correctly with Vulkan SDKs >= 1.3.290 where the Validation Layer requires Vulkan API 1.1 to enable the debugPrintfEXTfeature

I guess this mislead me then?

Tbh. I'm a bit out of the loop and I'm having a hard time answering to requests like this ad hoc.

Can't we simply revert back to the initial state of the sample (when I wrote it)?

[SRSaunders]

I guess this mislead me then?

Well, I guess I should have said >290 (and not >= 290). Sorry about that - my bad.

Can't we simply revert back to the initial state of the sample (when I wrote it)?

That won't help. Your original unmodified sample used Vulkan API 1.1 which will exhibit the same VVL performance issues as you are seeing now. You can blame me for moving back to API 1.0. I should have moved to API 1.2 at least until the VVL fix was made by @spencer-lunarg.

I am sorry if I have been commenting too frequently or asking too many questions given your other commitments. Perhaps you did not have time to appreciate the details of what I was asking.

I think it would be best for me to push the workaround that will fix this once and for all.

[SRSaunders]

@SaschaWillems and @spencer-lunarg: Commit https://github.com/KhronosGroup/Vulkan-Samples/pull/1133/commits/c209e6b86f4a31342eac9a2fa017d54ed64efd08 should fix perf issues for sample _shaderdebugprintf.

In my testing this fixes performance and vertex visibility when using SDK 1.3.290 (and earlier). If you see otherwise, please let me know including the test conditions (e.g. SDK version, platform, etc.) that cause it.

[SaschaWillems]

I feel kinda dumb, but this only works for me when NOT using the debug printf setting via vkconfig. If I use that preset, I don't see any vertex position output. It's very much possible that I'm doing something wrong. but I'm not sure what. I'm not sure why the code has an if clause for the layer setting extension at all.

I'm kinda torn on whether we want to add temporary workarounds for bugs in the SDK.

Can't we simply wait for the fixed SDK to be released?

[spencer-lunarg]

So I am still trying to grasp the conversation (and background here)

From my 1000-foot pole view, I would just have this requires Vulkan 1.2 (since there is enough 1.2 devices in the wild now) and when the next SDK comes out, just bump it down to 1.1

[SRSaunders]

From my 1000-foot pole view, I would just have this requires Vulkan 1.2 (since there is enough 1.2 devices in the wild now) and when the next SDK comes out, just bump it down to 1.1

That’s effectively what this PR does. It just automates it at runtime so that you don’t have to go back later to change the code when a new SDK comes out, or worry about cases when running against a non-current SDK.

However if you are not happy with a runtime-based approach and instead prefer a static fix using API 1.2, please let me know and I can make the change.