spirv-val: Update memory semantics rules to match the specification#6096
Conversation
93024d9 to
a9ebc33
Compare
a9ebc33 to
bfa6d1a
Compare
bfa6d1a to
6b7df25
Compare
|
I see the glslang tests are failing due to the check for relaxed memory order with non-zero storage class semantics. @alan-baker how would you prefer to proceed?
|
If the fix for glslang is quick, we can hold off on this PR. Otherwise, we merge this and then there are likely two changes for glslang:
So if glslang could be fixed in a week or two that might be preferable. |
Okay, I will take a closer look at the glslang problem and let you know the status in a few days. |
This commit updates memory semantics validation rules to match Vulkan specification update KhronosGroup/Vulkan-Docs#2528 and the spirv-tools update KhronosGroup/SPIRV-Tools#6096 Signed-off-by: Natalia Gavrilenko <natalia.gavrilenko@huawei.com>
This commit updates memory semantics validation rules to match Vulkan specification update KhronosGroup/Vulkan-Docs#2528 and spirv-tools update KhronosGroup/SPIRV-Tools#6096 Signed-off-by: Natalia Gavrilenko <natalia.gavrilenko@huawei.com>
ccc3057 to
6246406
Compare
This commit updates memory semantics validation rules to match Vulkan specification update KhronosGroup/Vulkan-Docs#2528 and spirv-tools update KhronosGroup/SPIRV-Tools#6096 Signed-off-by: Natalia Gavrilenko <natalia.gavrilenko@huawei.com>
|
@natgavrilenko could you please rebase this PR on top of main? |
Updated validation of memory semantics to match the formal Vulkan memory model and the Vulkan specification: - Require non-empty storage class semantics for non-relaxed memory orders - Require non-relaxed memory orders for non-empty storage class semantics - Validate AtomicCompareExchange Unequal semantics with respect to its Equal semantics - Unify Vulkan error messages and validation rules Signed-off-by: Natalia Gavrilenko <natalia.gavrilenko@huawei.com>
6246406 to
ad25402
Compare
@alan-baker Done |
This commit updates the validation of memory semantics to match the formal Vulkan memory model and the Vulkan specification:
Closes #6216.
Summary of changes:
Note: According to the OpenCL specification, a relaxed mem_fence has no effect but is not explicitly forbidden.
Note: Similar to the original validation rule for the barriers, the new rule considers only UniformMemory, WorkgroupMemory, ImageMemory, and OutputMemory storage class semantics. According to the Vulkan specification, the other storage class semantics (SubgroupMemory, AtomicCounterMemory, and CrossWorkgroupMemory) are not supported by Vulkan.