KhronosGroup / KhronosGroup/Vulkan-ValidationLayers
GroupMemoryBarrierWithWaveSync function is ignored
- Dominant language
- C++
- Stars
- 1k
- Forks
- 504
- Avg merge
- 11h 35m
- Merged PRs (30d)
- 224
Description
**Environment:**
- OS: Ubuntu 26.04 LTS
- GPU and driver version: NVIDIA GeForce RTX™ 4070 SUPER - NVIDIA 595.71.05
- SDK or header version if building from repo: 1.4.350.1
- Options enabled (synchronization, best practices, etc.): 'GPU assisted validation'
**Describe the Issue**
The Vulkan Validation Layers trigger a false positive `SharedMemoryDataRace-RaceOnAtomic` error when non-atomic initialization of a `groupshared` array variable is followed by a subgroup-scoped control barrier (Slang function : `GroupMemoryBarrierWithWaveSync`) before subsequent `InterlockedAdd` operations within the same subgroup.
Even though the execution and memory visibility are properly synchronized at the `Subgroup` scope prior to atomic execution, the validation layer appears to require a full Workgroup-scoped execution barrier to clear the data race tracking state for Workgroup memory accesses.
Here the minimal code :
```slang
#define N_WAVES 256 / 32 // here the nvidia wave size is used
groupshared uint sharedBins[16 * N_WAVES];
[numthreads(256, 1, 1)]
void main()
{
uint waveBinsIndex = WaveGetWaveIndex() * 16;
if (WaveGetLaneIndex() < 16)
{
sharedBins[waveBinsIndex + WaveGetLaneIndex()] = 0;
}
//GroupMemoryBarrierWithGroupSync(); // works
GroupMemoryBarrierWithWaveSync(); // leads to validation error - SharedMemoryDataRace-RaceOnAtomic
uint index = waveBinsIndex + WaveGetLaneIndex() % 16;
InterlockedAdd(sharedBins[index], 1);
//...
```
I strongly simplify the code sample to focus on the issue, then it looses its initial purpose.
---
**Expected behavior**
The Validation Layer should recognize that `GroupMemoryBarrierWithWaveSync` establishes a valid happens-before relation between the non-atomic write (`sharedBins[waveBinsIndex + WaveGetLaneIndex()] = 0`) and the subsequent atomic operation (`InterlockedAdd`) for all invocations within that subgroup. No SharedMemoryDataRace-RaceOnAtomic warning/error should be emitted.
**Valid Usage ID**
```
Validation Error: [ SharedMemoryDataRace-RaceOnAtomic ] | MessageID = 0xe8f0e3c7
(Warning - This VUID has now been reported 10 times, which is the duplicate_message_limit value, this will be the last time reporting it).
[ Debug region: SplatsSortPass::DigitBinSizePerWGCountPass ] vkCmdDispatch(): A data race was detected on the shared memory variable "sharedBins" in local invocation index 131 while performing a atomic operation. (Likely against local invocation index 131)
The other access in this race was at:
Shader validation error occurred at /home/chtimy/Repositories/coconut/app/gaussian_splats/shaders/radix_sort/bins_count.slang:46:11
46: sharedBins[waveBinsIndex + WaveGetLaneIndex()] = 0;
^
Stage = Compute. Global invocation ID (x, y, z) = (131, 0, 0)
Command buffer (0)
Compute Dispatch Index 4
Shader Module (app/radix_sort/bins_count.slang:main)(0x26d000000026d) (internal ID 4)
Shader validation error occurred at /home/chtimy/Repositories/coconut/app/gaussian_splats/shaders/radix_sort/bins_count.slang:51:7
51: InterlockedAdd(sharedBins[waveBinsIndex + WaveGetLaneIndex()], 1);
^
Objects: 3
[0] VkQueue 0x55e251afbb10
[1] VkCommandBuffer 0x55e257204d20
[2] VkPipeline 0x2700000000270
```
**Additional context**
N/A
Contributor guide
Research direction
Start by reproducing the report with the minimal shader pattern in app/radix_sort/bins_count.slang, using GPU-assisted validation and the reported subgroup barrier. Trace the validation output at lines 46 and 51; done means the valid subgroup synchronization no longer produces SharedMemoryDataRace-RaceOnAtomic while the full-group barrier behavior remains correct.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- devtools, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100