fix(vulkan): work around RX 6700 XT task shader timeouts #1413

Closed
lucasmsqt wants to merge 1 commit from feat/msqt into main
lucasmsqt commented 2026-11-10 01:14:14 +00:00 (Migrated from github.com)

Summary

Enable the compute fallback for task + mesh draws on Windows for AMD Navi 22
(device ID 0x73df, including the RX 6700 XT). This works around driver timeouts
on the native task shader path. Mesh-only draws can still use native mesh shaders.

  • Preserve the shared task payload and the starting workgroup when large direct
    draws are split into batches.
  • Generate indirect mesh dispatch and vertex draw arguments on the GPU from the
    task count.
  • Retry eligible graphics pipeline creation with optimization disabled when
    the AMD driver returns VK_ERROR_UNKNOWN.
  • Enable raw BC color attachment views and size their render areas in compressed
    blocks.

Refs #996.

Validation

  • git diff --check and tests/test_mesh_fallback.py passed.
  • With the Builder's LLVM toolchain, 11 of 13 focused checks passed.
  • nx2/test_mesh_first_types.py still looks for the old native task condition.
  • nx2/test_bc_storage_views.py uses a fixture whose Texture lacks the bc member.
  • The full local suite also encountered missing dependencies and Windows
    symlink permission errors.

Hardware verification

On a Windows RX 6700 XT, record the driver version and replay a scene that
previously triggered a timeout. Confirm that the log reports the compute fallback.
For a comparison run, set RX_VK_TASK_MESH_FALLBACK=0 to use the native path.

## Summary Enable the compute fallback for task + mesh draws on Windows for AMD Navi 22 (device ID `0x73df`, including the RX 6700 XT). This works around driver timeouts on the native task shader path. Mesh-only draws can still use native mesh shaders. - Preserve the shared task payload and the starting workgroup when large direct draws are split into batches. - Generate indirect mesh dispatch and vertex draw arguments on the GPU from the task count. - Retry eligible graphics pipeline creation with optimization disabled when the AMD driver returns `VK_ERROR_UNKNOWN`. - Enable raw BC color attachment views and size their render areas in compressed blocks. Refs #996. ## Validation - `git diff --check` and `tests/test_mesh_fallback.py` passed. - With the Builder's LLVM toolchain, 11 of 13 focused checks passed. - `nx2/test_mesh_first_types.py` still looks for the old native task condition. - `nx2/test_bc_storage_views.py` uses a fixture whose `Texture` lacks the `bc` member. - The full local suite also encountered missing dependencies and Windows symlink permission errors. ## Hardware verification On a Windows RX 6700 XT, record the driver version and replay a scene that previously triggered a timeout. Confirm that the log reports the compute fallback. For a comparison run, set `RX_VK_TASK_MESH_FALLBACK=0` to use the native path.
NotRexed commented 2026-11-10 02:08:06 +00:00 (Migrated from github.com)

Thanks for digging into the RX 6700 XT timeouts. Forcing the compute fallback by device ID changes every task+mesh draw on that card, and we cannot verify it on the hardware here. It also conflicts with the mesh-fallback fixes coming in v2.0.12 (#1314, #1317, #1383). Closing for now. If the timeouts still happen on v2.0.12, a report with the driver version and a log would help us find the native-path cause.

Thanks for digging into the RX 6700 XT timeouts. Forcing the compute fallback by device ID changes every task+mesh draw on that card, and we cannot verify it on the hardware here. It also conflicts with the mesh-fallback fixes coming in v2.0.12 (#1314, #1317, #1383). Closing for now. If the timeouts still happen on v2.0.12, a report with the driver version and a log would help us find the native-path cause.
lucasmsqt commented 2026-11-10 02:18:44 +00:00 (Migrated from github.com)

Got it, that makes total sense to close it for now to avoid conflicting with v2.0.12. I'll wait for the release, and if the timeouts still happen on the new version, I'll open a new report with logs and the driver version as suggested. Thanks for the update!

Got it, that makes total sense to close it for now to avoid conflicting with v2.0.12. I'll wait for the release, and if the timeouts still happen on the new version, I'll open a new report with logs and the driver version as suggested. Thanks for the update!
Commenting is not possible because the repository is archived.
No description provided.