[Proposal] Enabling extra OpenGL extensions at startup. (specifically mesh shading and SPIR-V)

[Kuba663]

What

OpenGL allows Mesh Shaders in 4.6 and since LWJGL seems to support them¹. It seems to be the same for SPIR-V². I propose adding an optional per-compatible device support for those features.

Why

Using task/amplification shaders to cull meshlets which are then sent to mesh shaders is faster (and easier) than generating real geometry from virtual geometry in compute shaders and SPIR-V is a binary format which makes it faster to link shader programs, which will improve loading times.
Additinally, the new mesh pipeline could help speed up lighting calculations.

How

GL.getCapabilities(), then using different implementations of rendering systems.

Potential problems

• Increased development time, hence this should have lower priority.
• It will require us to rewrite the entire rendering pipeline since Mesh and Vertex shaders don't seem to lik eeachother very much.
• Modders might just straight up ignore it or force SPIR-V onto their mods, which would cause a deluge of mods with compatibility issues since the extensions are rather new and OpenGL and Metal don't like eachother.
• ARR binary shader pack collision hell.

What I am not proposing

Making Kirino NVidia exclusive
Forcing SPIR-V

Extras

Rewriting vanilla mob model classes (ModelBiped etc.) to use the new pipeline. Meshlet generation will be easier since there is no non-convex geometry in those, as they are made of cubes.

References

1. https://javadoc.lwjgl.org/org/lwjgl/opengl/EXTMeshShader.html
2. https://github.com/LWJGL/lwjgl3/blob/a73648fbfcbc0945e9a0ffa2a3dca021c372f3b2/modules/lwjgl/opengl/src/generated/java/org/lwjgl/opengl/GL41.java#L92

[tttsaurus]

I would like such extension system to be generalized and have minimal impact on the current architecture, ideally as a simple opt-in mechanism. We can discuss later if mesh shading and spirv are actually needed once such a mechanism exists.

I don't think plain GL.getCapabilities() checks with if-else are sufficient to make things work smoothly while remain maintainable and scalable. We'll need service locator like systems or the virtual resource mechanism (like the ResourceSlot that I just implemented).

For example, when Direct State Access is supported, we can just instantiate a DSA-backed class and pass it to where requested. However, the boundary for applying an extension is whether the extension break existing implicit relationships between modules. If we'll have to rewrite another module to accommodate the changes of utilizing an extension, that extension would be considered not worth adopting.

Moreover, the architectural boundary I just mentioned would help us to evaluate the demand of mesh shading and spirv. I'd prefer to implement a minimal extension system and it'll help us to envision the roadmap further.

[v1993]

FWIW, from real-world experience with emulators it seems dubious if SPIR-V support is even worth it; only devices known to work well with and actually benefit from SPIR-V under OpenGL are those running Mesa. Even then, since Mesa has a shader cache, load times are unlikely to be meaningfully different after the first start.