-
Notifications
You must be signed in to change notification settings - Fork 186
Usage of atomicAdd()
causes shader compilation error
#564
Comments
Trying to reproduce this on http://shader-playground.timjones.io/, I'm getting:
|
So having recreated this I get the same result. I'm not sure how this relates to what I could/should change in my usage of the shader in my project. |
Could you run the application via Visual Studio? To do that, you can just "Open Project" and point it to already compiled executable. What this gives you is D3D12 validation output, which will say what exactly is the problem with the generated shader. |
I have not done this before so I may have done this wrong, but as you said I opened a new project by selecting the release executable then pressing start in visual studio to run it. The resulting debug terminal output:
|
Looks like it's failing before even reaching D3D12. There is only SPIRV-Cross in there. |
Are you able to recreate the errors by running the test project/executable? |
Did this now. I incorrectly assumed you were on D3D12, but you really are running on Vulkan backend.
TL;DR: you are trying to use the subgroup operations. WebGPU doesn't support them yet, and we don't have a native-only extension either. See gpuweb/gpuweb#954 |
Im not sure if this is accurate, maybe you meant to say it doesn't support atomic operations? The shader in the project I shared uses the subgroup operation I also have a variety of other shaders which implement |
Perhaps, it's my machine only that doesn't support the subgroups? Could you hook up env_logger and check the vulkan validation messages on your machine? |
I'm not very unfamiliar with using Vulkan validaiton layers, having never really used them. Using LunarG VulkanSDK and selecting a validation layer through it is how I've previously done it, although even this I have not really used. So I'm not sure how to do what you ask. Just in case this is along the lines of what you where looking for, this is the output when enabling the standard validation layer in VulkanSDK:
|
Interesting. So on your machine there appear to be no validation errors reported by VVL, and it just fails to create the pipeline. |
I'm not quite sure of the state of this issue what should be done to move forward here, is this simply a bug you are looking into? Is there anything else I can do here? |
First step - figuring out what exactly happens there, and why we end up with "Compilation failed". |
Apologies for my inexperience here, but I have no idea how I would do this (or even where I should look to learn how to do this, even being able to see the result of validation layers I don't know how to interpret the output). |
Thank you for not hesitating to reach out. We'll be happy to guide you through. |
Can do (stepping through it all rn). |
So stepping through and into everything, it seems to crash when stepping into Just to make it clear as possible, this function: pub fn device_create_shader_module<B: GfxBackend>(
&self,
device_id: id::DeviceId,
source: pipeline::ShaderModuleSource,
id_in: Input<G, id::ShaderModuleId>,
) -> Result<id::ShaderModuleId, pipeline::CreateShaderModuleError> { The debugger highlights the line of the function name, then when stepped into, crashes. Just to clarify are you unable to replicate the error on your system? (I just updated the test project to make sure it's right: test-project.zip) |
Something in compile_shader_module returned an error. If you could step through and see, what exactly, that would be helpful. |
So after hitting this breakpoint: And stepping into, it results in: Stepping into again results in the notification just reopening and no progress. Stepping over has the same result. Pressing continue however results in: Pressing continue again at this point results in: Here the program has excited. Playing around with breakpoints a bit more I am able to step through the function a bit more, ultimately it steps through until hitting the same breakpoint (at the function name) and exciting by opening this file this time: |
Hmm, I don't understand. You aren't able to step by step within this function? Perhaps, you are working with a release build? |
What happens when you run the project on your machine with |
As I mentioned in #564 (comment), running your test_project (after hooking up |
In #564 (comment) the outputs here are not the result of using
Are you reffering to this https://github.com/gfx-rs/wgpu-rs#simple-setup? So just setting this up (Without setting
Is this familiar? |
Yep, it looks like you aren't getting the errors I'm getting. What version of the Vulkan SDK do you have installed? I have "vulkan-validation-layers, version: 1.2.141.0, release: 9". |
I beleive I have the latest version (from https://vulkan.lunarg.com/sdk/home). Vulkan configurator->Tools->Vulkan Info:
But in #564 (comment) it is not running (or atleast I have not manually done anything involving it, I haven't opened the Vulkan configurator), I'm unsure why it would matter to the result of |
I don't know how your system is configured. Generally, we intercept the validation messages and put them into Anyhow, I can't reproduce the situation you have without triggering validation errors. Perhaps, the test case you shared is not the one you are running? |
To give an overview: This is the test project (this should be same as other links, but this is just to be safe): test-project.zip I am ofc excluding warnings in outputs here. This is the simple output (without Vulkan configurator running in background and with
This is output with This is output with This is output with Vulkan configurator in background using the standard validation layer: https://hastebin.com/unomasojud.rb (requires running using |
I hate to be annoying (this issue has already reached quite the length), but I have no idea how to move forward with this bug. Could you cexplain how you got the |
@JonathanWoollett-Light I did mention that it's useful to hook up |
The difference leading to the errors you mention in #564 (comment) is setting Perhaps you assumed by mentioning The outputs of 2 logging approaches when
|
Bummer, it's my bad. I got confused about the backends again. I keep thinking that it's the D3D12 you are having issues with... Sorry! And I appreciate you bearing with me here 👍 So, testing your latest code on Vulkan, I get the following validation error:
This would perfectly explain the "failed to create shader module" error you are having. I wonder why you are not seeing this error? Maybe your validation layers are older? |
How would I check this? Just to be as clear as possible, when running the project (
|
Here are possible things for you to do:
|
So I 've had this installed for quite a while, there are a bunch of configs for validation layers and I'm not sure what is relevant. Is there a particular validaiton layer config to go for? The configs:
So downloading the windows release from here and running the validator
I have no idea what these errors mean or what to do with them (and I can't find any reference or explanation). |
This all is relatively new. The "Standard" should work, at least.
Ok, so I think we cleared up the unknowns by now. If you are wondering why The tool you used to produce SPIR-V ( From your side, stripping the code of atomic adds should let the tool to produce the module without that capability required. |
So I can't find where to report bugs for VulkanSDK, any idea? |
According to https://github.com/google/shaderc:
So it's either |
Issue google/shaderc#1140 was filed against Shaderc. The root cause is that the copy of spirv-val that you have is out of date, and did not have information about the SPV_EXT_shader_atomic_float_add extension. Verison 1.2.154 of the Vulkan SDK was released in early October, and should have an update spirv-val. |
@kvark Does #564 (comment) seem like something that makes sense that could be fixed? |
@JonathanWoollett-Light wgpu doesn't include spirv-val. This comment means you would need to update spirv-val locally (i.e. probably updating Vulkan SDK, or however spirv-val is installed on your computer) |
@grovesNL So I updated Vulkand SDK from 1.2.148.1 to 1.2.154, and used:
to recompile the shader in the test project. The error given by attempting to run the program (
The errors given by the validator also remain unchanged:
This doesn't seem to have had any affect, am I missing something here? |
@dneto0 is there an issue to track with regards to |
@JonathanWoollett-Light Interestingly, google/shaderc#1140 (comment) reports no evidence of the issue on latest toolchain. So maybe your experiment didn't do the same thing? If I were you, I'd probably start cutting out the stuff from the shader (especially use of new extensions) to see where it starts to break, just to get a better understanding of the problem. In any way, this will only become |
@kvark So in updating to use the latest https://github.com/KhronosGroup/SPIRV-Tools download version using
Assuming I have done this correctly, the shader has been correctly compiled, does this not then imply an error in
It is any usage of |
Whan you are passing this shader to |
@kvark Yes, I believe the exact same validation errors as in #564 (comment).
|
No, these are unrelated. I was asking about "CoreValidation-Shader-InconsistentSpirv", and it looks like you are no longer getting it, yet the shader still fails to compile. Can you share the updated test case/app? |
Updated project: test-project.zip |
Thank you! I had another look at this. The problem is that the SPIRV shader you are feeding to us requires The Vulkan validation layers are not comprehensive, and they miss this problem. But it's still invalid usage of Vulkan. Notably, the WebGPU group hasn't discussed anything with regards to floating point atomics yet. We could expose a native-only feature for this capability. |
I believe it is quite a fundemental component required for many compute operations. It would be great if it could be used. |
Filed gfx-rs/wgpu#1020 and added an entry to https://github.com/gfx-rs/wgpu/wiki/Extensions |
@kvark Could you guess at any eta for gfx-rs/wgpu#1020? (Apologies if this comes off as rude it would just be useful to know) |
@JonathanWoollett-Light there is no ETA. It's a feature that hasn't been requested before, and not in the spec, so it's a classy thing for "scratch the itch"-driven development, where somebody who needs it contributes the feature and maintains it (there isn't much to maintain here, fortunately). |
Using
.spv
file of a compiled shader which includes the functionatomicAdd()
, in this case specifically:When run (with
cargo run --release
) leads to the error:It does not cause an error when the GLSL code is compiled to SPIR-V.
Compiled with the command:
Notably enabling the extenson does not cause an error (using
#extension GL_EXT_shader_atomic_float: enable
is fine, it is only when adding the usage ofatomicAdd()
does the error occur).Test project: test-project.zip
The text was updated successfully, but these errors were encountered: