Resolve VVL warning on incompatible OpTypeImage vs. image view format
Description
One possible way to resolve the VVL warnings on incompatible OpTypeImage, without the need of additional extensions.
Just needs to switch the generated image from BGRA8 to RGBA8, and overwrites the function create_render_context to enforce selection of an RGBA surface format.
Build tested on Win10 with VS2022. Run tested on Win10 with NVidia GPU.
Fixes #1423
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
- [x] I have tested every sample to ensure everything runs correctly
- [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)
- [ ] 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
batchcommand 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
I'd prefer using shaderStorageImageRead/WriteWithoutFormat and the GL_EXT_shader_image_load_formatted GLSL extension. This is widely supported. Afaik all devices that offer HW ray tracing also support that feature (which is a Vulkan 1.0 feature). Having to specify image formats in the shader is actually a legacy OpenGL thing. I do that in my own samples too btw.
I'd prefer using shaderStorageImageRead/WriteWithoutFormat and the GL_EXT_shader_image_load_formatted GLSL extension.
But it would require support of that extension. I don't know anything about its availability.
Besides that, is BGRA8 in any respect "better" than RGBA8?
If so, we could make the shaderStorageImageWriteWithoutFormat feature optional, and use the appropriate format depending on the support of that feature.
No, it only requires support for shaderStorageImageRead/WriteWithoutFormat. And those are universally supported.
Would it require something more than just requesting that shaderStorageImageWriteWithoutFormat feature?
If I request that in request_gpu_features like so:
if (gpu.get_features().shaderStorageImageWriteWithoutFormat)
{
gpu.get_mutable_requested_features().shaderStorageImageWriteWithoutFormat = VK_TRUE;
}
else
{
throw std::runtime_error(std::string("Required feature <VkPhysicalDeviceFeatures::shaderStorageImageWriteWithoutFormat> is not supported"));
}
I still get the same VVL warning. Would I have to do something with the actual shaders?
... and requesting both, shaderStorageImageReadWithoutFormat and shaderStorageImageWriteWithoutFormat doesn't resolve that warning either.
What shader language are you using? GLSL, HLSL or Slang?
What shader language are you using? GLSL, HLSL or Slang?
I'm using the default, which I think is GLSL.
You need to remove the explicit image format from the shader and (At least for GLSL) need to enable the required extension.
E.g.
#version 460
#extension GL_EXT_ray_tracing : enable
#extension GL_EXT_shader_image_load_formatted : enable
layout(binding = 0, set = 0) uniform accelerationStructureEXT topLevelAS;
layout(binding = 1, set = 0) uniform image2D image;
With this change and enabling both features, the validation error no longer shows up.
@SaschaWillems I think, it's easier, when you craft a PR to resolve that issue using those features?
Sure, see #1452 :)