KhronosGroup / KhronosGroup/Vulkan-ValidationLayers
gpuav: An OOB that triggers in a task shader causes a GPU hang/crash
- Dominant language
- C++
- Stars
- 1k
- Forks
- 504
- Avg merge
- 11h 35m
- Merged PRs (30d)
- 224
Description
When gpuav is enabled and the task shader performs an OOB access, the resulting command seems to crash the GPU. No validation diagnostics about the OOB access is printed; the only externally visible effect is that the device gets lost. The code happens to run without any issues when gpuav is disabled; fixing the OOB access fixes this problem too.
Expected behavior would be to print the actual OOB access message before anything bad happens.
**Reproduction**
Clone and build niagara project with GPUAV enabled:
```
git clone https://github.com/zeux/niagara --recursive
git checkout eefec2794681a1f8416e1fcc2771c1cdc11a86cb
cmake .
make -j8
```
Run it on the provided .obj file, and press T to activate task shader path:
```
./niagara data/kitten.obj
```
> Note: you might need to disable descriptor heap usage with `DESCHEAP=0` env var because gpuav doesn’t seem to support OOB access when they are used; setting `CONFIG_GPUVAL` in `src/config.h` does that automatically.
The task shader (`src/shaders/meshlet.task.glsl`) has an out of bounds access to `meshlets` buffer. Fixing that fixes the issue, but while left unfixed, the issue is difficult to diagnose because there is no indication as to which access or resource is being accessed and that an OOB access is even taking place.
**Environment:**
- OS: Ubuntu Linux 26.04
- GPU and driver version: NVIDIA GeForce RTX 5070, 610.43.02
- SDK or header version if building from repo: 1.4.357
- Options enabled (synchronization, best practices, etc.): gpuav
Contributor guide
Assessment
This issue has not been assessed yet.