RADV Continues Getting Ready For Vulkan Mesh Shader Support

[phoronix]

Phoronix: RADV Continues Getting Ready For Vulkan Mesh Shader Support

Merged yesterday into RADV for Mesa 22.2 is implementing task/mesh shader draw support...

https://www.phoronix.com/scan.php?page=news_item&px=RADV-Mesh-Shader-More-Progress

[FireBurn]

Is there anything out there that uses this extension that we can go and test?

[mdedetrich]

However, the NV_mesh_shader extension with RADV remains hidden by default unless using the RADV_PERFTEST=nv_ms environment variable.

Why is this the case? Its an extension so I don't see how it can break any existing functionality or is it the fact that its still WIP?

[Wielkie G]

Why is this the case? Its an extension so I don't see how it can break any existing functionality or is it the fact that its still WIP?

I believe the functionality advertised by the NV extension does not exactly match what AMD hardware can do, so the implementation is suboptimal in a few places. I think one problematic part is being able to emit vertices and primitives before setting their amount in the mesh shader. This might result in worse performance while using this extension compared to the legacy primitive pipeline.

[mdedetrich]

I believe the functionality advertised by the NV extension does not exactly match what AMD hardware can do, so the implementation is suboptimal in a few places. I think one problematic part is being able to emit vertices and primitives before setting their amount in the mesh shader. This might result in worse performance while using this extension compared to the legacy primitive pipeline.

Is this going to be addressed at some point?

[Nille]

Is this going to be addressed at some point?

If its a hardware limitation its doubtful. The question is how the final extension looks like if its finished.

[Wielkie G]

Yes, the issue is about the NV specification which is tailored to the NV hardware. The vendor-agnostic KHR mesh shader extension is likely to be efficient on AMD hardware.

https://github.com/KhronosGroup/Vulkan-Docs/issues/1423#issuecomment-1161955567

[Venemo]

Why is this the case? Its an extension so I don't see how it can break any existing functionality or is it the fact that its still WIP?

1. We don't want to officially support NV_mesh_shader (reasons already explained by another person here), we implemented it only to get some experience and understanding about the new shader types.
2. NV_mesh_shader support will be removed soon after a cross-vendor extension appears, so we don't want anyone to start relying on it.
3. It's not WIP on the RADV side, however it is not fully reliable without the "gang submit" kernel feature.

Is this going to be addressed at some point?

The vendor neutral extension is going to be more like D3D12 (see Khronos Github for details).
However, we won't enable support for that either until "gang submit" is merged in the kernel. This is because otherwise it is prone to deadlock the GPU.

[timofonic]

1. We don't want to officially support NV_mesh_shader (reasons already explained by another person here), we implemented it only to get some experience and understanding about the new shader types.
2. NV_mesh_shader support will be removed soon after a cross-vendor extension appears, so we don't want anyone to start relying on it.
3. It's not WIP on the RADV side, however it is not fully reliable without the "gang submit" kernel feature.

The vendor neutral extension is going to be more like D3D12 (see Khronos Github for details).
However, we won't enable support for that either until "gang submit" is merged in the kernel. This is because otherwise it is prone to deadlock the GPU.

When will "gang submit" be merged to the kernel?

[Venemo]

When will "gang submit" be merged to the kernel?

Good question. The kernel development cycle is really slow. If the developers merge this into 5.21 that means you can play with it in about 6 months.

Until then, you can still use the environment variables. (Unless find some other solution in the meantime.)