-
Notifications
You must be signed in to change notification settings - Fork 686
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
Add sample for dynamic rendering local read #887
Add sample for dynamic rendering local read #887
Conversation
Required for samples that don't use render passes
Initialize base color Removed assert that would trigger on some basic glTFs Refs KhronosGroup#848
Copy from internal git repository
Fix clang format
I'm having trouble with getting the clang format right. I'm on VS 2022 (latest version) and I don't know why our clangformat does fail. It fails on this: VkPipelineRenderingCreateInfoKHR pipeline_rendering_create_info{VK_STRUCTURE_TYPE_PIPELINE_RENDERING_CREATE_INFO_KHR};
pipeline_create_info.pNext = &pipeline_rendering_create_info; Which looks totally fine to me and is the same as the already existing dynamic rendering sample. I can only imagine that our script can't cope with code inside of pre-processor blocks. clang_format.py only works for me in WSL but it tells me that everything is fine and does not change any of the files... I noticed that our documentation still says "clang-format 8", my WSL setup is already at 14. I'd rather not downgrade. Any ideas @tomadamatkinson? Maybe we can discuss this at our next meeting. Tbh. the clang format stuff is driving me mad for pretty much every sample I write :( |
samples/extensions/dynamic_rendering_local_read/dynamic_rendering_local_read.cpp
Outdated
Show resolved
Hide resolved
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.
Some first comments...
@@ -566,7 +566,10 @@ ApiVulkanSample::~ApiVulkanSample() | |||
vkDestroyDescriptorPool(device->get_handle(), descriptor_pool, nullptr); | |||
} | |||
destroy_command_buffers(); | |||
vkDestroyRenderPass(device->get_handle(), render_pass, nullptr); | |||
if (render_pass != VK_NULL_HANDLE) |
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.
No need to check for (render_pass != VK_NULL_HANDLE)
here, as vkDestroyRenderPass can handle that.
samples/extensions/dynamic_rendering_local_read/dynamic_rendering_local_read.cpp
Show resolved
Hide resolved
samples/extensions/dynamic_rendering_local_read/dynamic_rendering_local_read.cpp
Show resolved
Hide resolved
samples/extensions/dynamic_rendering_local_read/dynamic_rendering_local_read.cpp
Show resolved
Hide resolved
samples/extensions/dynamic_rendering_local_read/dynamic_rendering_local_read.cpp
Show resolved
Hide resolved
Just a quick note, that this code isn't 100% matching the internal version of the sample. Thanks for the feedback though, I'll take a look at it once the internal issues are solved. |
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.
Any reason, you made the dynamic rendering a compile-time switch instead of a run-time switch?
samples/extensions/dynamic_rendering_local_read/dynamic_rendering_local_read.cpp
Show resolved
Hide resolved
Makes it easier to maintain the sample. The render pass path is just there so people can easily see the differences in code. |
This reverts commit 7504395.
Would require fixes to the framework
@tomadamatkinson : I'm struggling to get this to pass all checks. The pre-commit clang format step did something but it still fails, and I don't have a clue how to fix it. Running the clang format script manually shows some files, but nothing is actually changed. I also don't know why the doxgen checks are failing now :( Also no idea why Android is failing all of a sudden :( |
And it looks like I made the mistake of committing and pushing files with merge conflict info still present :/ Maybe I should refrain from adding new samples until we are done with the framework rework. |
Still fails with clang format and I have no clue why. I guess it's because I'm making heavy use of compiler directives? Running the script locally lists some files, but doesn't help with the problem sadly: This list of files doesn't match with the ones from the CI failure. It looks like it did something, but no local changes or commit are generated. |
Have tried this on linux, but there is only support for this example on NVIDIA platforms at this moment. Will try to test on windows later this week. When building I had to turn off the opencl interop example due to out of sync changes. |
Sorry, totally forgot to merge main into this. I've merged and pushed the branch, so it should compile fine now. And thanks for testing :) |
Works without any issue on:
If you need more tests on other platforms/architectures, please let me know |
Silly question... where do I find the assets used with this sample ( |
@asuessenbach you can checkout the next PR KhronosGroup/Vulkan-Samples-Assets#23 |
@jeroenbakker-atmind Thanks, now it runs fine here as well: Win10, NVIDIA RTX A3000 Laptop |
The gui is only available when When I just prepare the gui even if |
Yes, that layer message is the reason the GUI is disabled by default. For the GUI to work with that sample I would have to do some extensive changes to the GUI framework class. I may do that once this sample has been merged in a separate PR. |
IMO not correct, but the only way to get that build step running
I can still test on NVIDIA GTX 980 + 760 IIRC only the 980 will support this. |
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.
I noticed the following running this with Vulkan SDK 1.3.290:
[error] 269944751 - VUID-RuntimeSpirv-NonWritable-06340: Validation Error: [ VUID-RuntimeSpirv-NonWritable-06340 ] Object 0: handle = 0xc25f26000000009c, type = VK_OBJECT_TYPE_SHADER_MODULE; | MessageID = 0x101707af | vkCreateGraphicsPipelines(): pCreateInfos[0].pStages[1] SPIR-V (VK_SHADER_STAGE_FRAGMENT_BIT) uses descriptor [Set 0, Binding 3, variable "LightsBuffer"] (type VK_DESCRIPTOR_TYPE_STORAGE_BUFFER or VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC) which is not marked with NonWritable, but fragmentStoresAndAtomics was not enabled. The Vulkan spec states: If fragmentStoresAndAtomics is not enabled, then all storage image, storage texel buffer, and storage buffer variables in the fragment stage must be decorated with the NonWritable decoration (https://vulkan.lunarg.com/doc/view/1.3.290.0/windows/1.3-extensions/vkspec.html#VUID-RuntimeSpirv-NonWritable-06340)
Thank you very much for testing. That validation message seems to have been introduced by a recent SDK. I added the readonly attribute to the buffer mentioned in that message. |
Merging - 3 approvals |
PR KhronosGroup#887 predated vkb::core::CppBuffer merge, change type used to BufferC
Description
This PR adds a new sample that shows how to replace render passes + multiple sub passes with dynamic rendering and the new
VK_KHR_dynamic_rendering_local_read
extension. The sample contains code paths for both those setups which can be toggled via a pre-processor define.The sample also comes with a small tutorial that explains some of the differences.
Note: This is a copy of the sample from the internal gitlab. With the extension now public, we can continue on this over here.
Note: Requires assets from KhronosGroup/Vulkan-Samples-Assets#23, so that PR needs to be merged before or right after this PR has been merged.
Tested on Windows 11 with an NVIDIA RTX 4070 and the latest public Vulkan developer driver.
General Checklist:
Please ensure the following points are checked:
Note: The Samples CI runs a number of checks including:
Sample Checklist
If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist: