KhronosGroup / KhronosGroup/Vulkan-ValidationLayers

gpuav: An OOB that triggers in a task shader causes a GPU hang/crash

Open
#12,806 0 comments 1 reaction 1 assignee Claimed by @spencer-lunarg View on GitHub
GPU-AV
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.