Draft: Add GL_EXT_mesh_shader

[yuq]

This is an OpenGL extension forking VK_EXT_mesh_shader to provide OpenGL mesh shader functionality.

Numbers in the spec haven't been allocated, so use fake numbers for now. No header/XML updates in the PR either.

This extension is for the request of nvidium users to add OpenGL mesh shader support to drivers other than NVIDIA GPUs:

• mesh shader support? GPUOpen-Drivers/AMD-Gfx-Drivers#4
• https://gitlab.freedesktop.org/mesa/mesa/-/issues/12189

[oddhack]

Re discussion on the mesa issue, Khronos does not "approve" new vendor extensions, though we do try and consistency-check them and make sure they're following the extension guidelines before we include them in the extension registry and hand out enum allocations. It's true that GL spec activity is very minimal within Khronos, but vendor and EXT extension development do not have to happen inside Khronos.

So the first thing to ask is whether there is a commitment to implement this on the part of someone actually writing Mesa drivers. There's no point in publishing an extension spec in the registry if nobody has implemented it. Then, how and why does it differ from the NV extension? I see a slight signature change on one of the APIs but haven't tried to review the whole thing. Because of the close relationship between them, there should at least be a section down around the "Interactions" discussing the things that are the same, and those that had to be changed, and why.

Would it be possible to implement the NV extension as it stands today on your target GPUs, and then add a really small extension on top of that to accommodate the changed signature, rather than duplicate so much of that language?

BTW, when promoting an extension we keep the enum values unchanged so long as they are indistinguishable semantically from the point of view of the driver they are passed to. Only if there's a need to behave differently depending on which extension is being used would the enum value need to change.

[yuq]

Re discussion on the mesa issue, Khronos does not "approve" new vendor extensions, though we do try and consistency-check them and make sure they're following the extension guidelines before we include them in the extension registry and hand out enum allocations. It's true that GL spec activity is very minimal within Khronos, but vendor and EXT extension development do not have to happen inside Khronos.

Thanks for the explanation.

So the first thing to ask is whether there is a commitment to implement this on the part of someone actually writing Mesa drivers. There's no point in publishing an extension spec in the registry if nobody has implemented it.

Yeah, I'm going to implement it in mesa if it's accepted.

Then, how and why does it differ from the NV extension? I see a slight signature change on one of the APIs but haven't tried to review the whole thing. Because of the close relationship between them, there should at least be a section down around the "Interactions" discussing the things that are the same, and those that had to be changed, and why.

The difference with NV extension has been listed in the issue Q&A:

• https://github.com/yuq/OpenGL-Registry/blob/topic/mesh-shader/extensions/EXT/EXT_mesh_shader.txt#L1127
• https://github.com/KhronosGroup/GLSL/blob/main/extensions/ext/GLSL_EXT_mesh_shader.txt#L1029

Would it be possible to implement the NV extension as it stands today on your target GPUs, and then add a really small extension on top of that to accommodate the changed signature, rather than duplicate so much of that language?

It's not possible to stack a new extension on NV. Because the NV extension interface (mostly GLSL part) is not suitable for other GPU vendors, that's why Vulkan created VK_EXT_mesh_shader. We can implement NV extension with many ugly workaround in driver, but it will hurt performance:

• https://gitlab.freedesktop.org/mesa/mesa/-/issues/7192#note_1822130

BTW, when promoting an extension we keep the enum values unchanged so long as they are indistinguishable semantically from the point of view of the driver they are passed to. Only if there's a need to behave differently depending on which extension is being used would the enum value need to change.

The runtime API part mostly come from the VK_EXT_mesh_shader to leverage the existing agreement made by different GPU vendors. I can keep the enum value which is same as NV extension and assign a fake value for the new ones.

[Venemo]

Hi,

So the first thing to ask is whether there is a commitment to implement this on the part of someone actually writing Mesa drivers.

Yes, there is interest in implementing it in RadeonSI as well as in Zink (which would work on top of the Vulkan EXT_mesh_shader exposed by the underlying Vulkan driver).

Then, how and why does it differ from the NV extension?

there should at least be a section down around the "Interactions" discussing the things that are the same, and those that had to be changed, and why

Would it be possible to implement the NV extension as it stands today on your target GPUs

Same as the Vulkan NV vs. EXT extensions. In a nutshell, the NV extension makes it impossible to implement mesh shaders with reasonable performance on other vendors's HW; and EXT fixes that. Furthermore, EXT is better aligned with D3D12 mesh shaders and therefore benefits developers by providing a more familiar programming model.

If you are interested in the exact details, they have been discussed in the Vulkan EXT_mesh_shader blog post and also on the spec MR here, among other places. This comment in the Mesa repo goes through the main issues with implemeing the NV extension on HW that wasn't designed for it.

[zmike]

I'd like to see the mesa implementation at least well underway before this is released, but I think it's a great addition to the ecosystem. Bringing cross-vendor support to GL mesh shading will enable things like nvidium to finally run on more platforms.

[yuq]

Then can the numbers be allocated first, so that I can update headers and start implementation?

[zmike]

Yeah that seems good. @oddhack do you take care of that or am I supposed to do something?

[oddhack]

Then can the numbers be allocated first, so that I can update headers and start implementation?

@yuq how many do you need? We allocate in blocks of 16. I think I counted 62 enums in the spec as it stands, so I can give you a block of 64 if you need that many (the new bit values not included in that total since they are semantically in a different namespace).

[yuq]

I need 22, aligned to 16 is 32. I reused some enum numbers from GL_NV_mesh_shader, only those begin with 0xF need to be allocated.

How about the extension serial number (I fake to 1024)? Do they have to be allocated when release?

[oddhack]

I need 22, aligned to 16 is 32. I reused some enum numbers from GL_NV_mesh_shader, only those begin with 0xF need to be allocated.

How about the extension serial number (I fake to 1024)? Do they have to be allocated when release?

Done, see d8fdb8d (enums 0x9740-0x975F).

The extension number is assigned when we publish. It isn't actually used as anything but an ordering mechanism.

[yuq]

OK, thanks.