u/MortixTheGuy

I'm working on a fully GPU-driven Vulkan renderer using mesh shaders and vkCmdDrawMeshTasksIndirectCountEXT.

I wanted to collect some frame statistics with a VK_QUERY_TYPE_PIPELINE_STATISTICS query pool. The classic statistics (fragment, clipping, etc.) work fine and have basically no measurable overhead.

However, as soon as I enable:

VK_QUERY_PIPELINE_STATISTIC_TASK_SHADER_INVOCATIONS_BIT_EXT
VK_QUERY_PIPELINE_STATISTIC_MESH_SHADER_INVOCATIONS_BIT_EXT

GPU performance tanks.

Without these counters my frame is around 1–1.5 ms. With them enabled, more complex scenes jump to ~80 ms.

It seems to scale with the amount of work done by the task/mesh shaders more visible objects means more task/mesh shader invocations, and the performance degradation becomes much worse.

My main question is: is this expected? Do these invocation counters force the driver onto some slower path or disable optimizations to guarantee accurate statistics?

I'm mostly interested in whether this is a known limitation of the extension or an NVIDIA driver behavior.

I could easily implement my own counters using atomics/subgroup operations in the shaders, so I have a workaround. I just assumed the built-in pipeline statistics would be the cleaner solution.

System:

• RTX 4060
• Windows 11
• NVIDIA Driver 610.62
• Vulkan SDK 1.4.350.1

 

Has anyone else seen this?

I'm working on a really high-performance GPU-driven rendering engine and I've run into a use case where Work Graphs would be extremely valuable.

The engine uses hierarchical GPU culling throughout the pipeline (including shadow map rendering as well). Everything is GPU-driven and I'm trying to avoid CPU intervention as much as possible.

The main issue is worst-case allocation. While this can be mitigated to some extent, I still have to reserve buffers for the worst possible workload. In practice, this can become quite wasteful.

Of course, it's possible to allocate more conservatively and resize resources at runtime when necessary. For example, a shader can set a flag when it detects that a buffer is running out of space, and the engine can then reallocate a larger buffer on a subsequent frame. However, this adds complexity to the system and is ultimately a workaround rather than a clean solution.

I've experimented with task/mesh shaders as well. Task shaders help because the payload mechanism allows some level of work amplification and scheduling, but for deeper hierarchical structures the two-stage task → mesh shader model becomes limiting.

AMD has VK_AMDX_shader_enqueue, while DX12 already has Work Graphs, but Vulkan still doesn't seem to have a standardized equivalent.

So I'm curious:

• Is there a technical reason why Work Graphs haven't been standardized in Vulkan yet?
• Is there active Khronos discussion around a solution?
• Is NVIDIA interested in supporting such a model?

From an engine developer perspective, Work Graphs seem like a natural fit and a must have mechanism for GPU-driven rendering, culling...