-
Notifications
You must be signed in to change notification settings - Fork 863
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
glslangValidator not emitting Int64Atomics when expected #2975
Comments
This is using glslang at commit |
FWIW, same behavior on latest commit. |
paul-lunarg
added a commit
to paul-lunarg/Vulkan-ValidationLayers
that referenced
this issue
Jul 14, 2022
temporarily disable until issue fixed: KhronosGroup/glslang#2975
jeremy-lunarg
added a commit
to jeremy-lunarg/glslang
that referenced
this issue
Jul 14, 2022
This covers a corner case wherein imageAtomicStore is used exclusively. The proxy type for imageAtomicStore is inferred from the image type. Fix KhronosGroup#2975.
paul-lunarg
added a commit
to KhronosGroup/Vulkan-ValidationLayers
that referenced
this issue
Jul 16, 2022
temporarily disable until issue fixed: KhronosGroup/glslang#2975
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The validation layers have a test that effectively uses the following GLSL (this is contrived code, but expected to at least pass spirv-val):
Which produces the following error when running
spirv-val
:spirv-dis
shows that indeedInt64Atomics
is not there:Other
imageAtomic*
functions seem to cause theInt64Atomics
capability to get added. e.g., replacingimageAtomicStore
withimageAtomicExchange
emitsInt64Atomics
, and the resulting spirv validates successfully.Is there something special about
imageAtomicStore
such that it shouldn't emit theInt64Atomics
capability?The text was updated successfully, but these errors were encountered: