Just putting this out there since nobody else has said anything yet,it would be great for much better performance and not even needing any kind of shader cache since its so much faster.
The large downside is that Intel and AMD (go figure) GPUs don't support ARB Assembly shaders,only Nvidia cards work with it but the results are insane on Yuzu essentially eliminating all of the major stutters and even outperforming Vulkan's Spir-V shaders.
I hope that the devs of other emulators for 3D stuff can also try to implement it despite only working for Nvidia cards.
(AMD graphics drivers suck on Windows anyway and Intel drivers aren't much better,not sure about Intel Iris Graphics though)
Being open source,hopefully someone is nice enough to add this feature to significantly boost performance,especially on shader-heavy games like the Metroid Prime series without needing to use any uber shaders or likely any shader cache at all.
ARB Assembly was like a late nineties thing, and was short-lived and replaced by GLSL, so is very unlikely to use a well-optimised path. There's no way it's the thing you're talking about is that unless you're also completely wrong.
If footage of Yuzu running nearly without any stutters at all ins't enough proof,I don't know what is.
BSoD Gaming did a side-by-side comparison of GLSL vs. ARB and GLSL lags behind by a lot since the shaders in that case are so complex compared to previous generation stuff,its basically night an day in that example.
GLSL can take up to 3 seconds in some instances while all cases on ARB Assembly based shader compiling likely takes 1 second at most.
I would imagine it would be entirely seamless in Gamecube and Wii games,but only if it can work to begin with and somebody knows how to create the right assembly data to implement it.
Just look at the major improvements that Yuzu gained from using it.
Honestly I should've said specifically "Nvidia assembly" because there is indeed a difference to that and standard ARB Assembly that is very old.
That page says it works with modern GL 3.x and Yuzu uses that edition of it with great success even though its currently experimental.
Because it would remove all of the performance impact you get from using any form of Ubershaders on Dolphin due to not even needing it because its so much faster than GLSL to the point it even beats Vulkan's Spir-V shaders.
Judging from Yuzu's implementation,it clearly can be made optional to use Nvidia Assembly_ARB so it shouldn't make OpenGL unusable on AMD or Intel cards.
Keep in mind that changing the shading language used in Dolphin definitely isn't an easy task and thus I wouldn't expect anyone willing to go through all this work when the end results would just solve a problem we already solved through ubershaders, especially when said solution would work only on NVIDIA and only with OpenGL, in contrast of the existing ubershaders approach which works on all backends and on all GPUs that meet Dolphin's minimum system requirements...
I think SPIR-V would be much more beneficial. It seems to be quite a bit quicker at compiling than GLSL, not as quick as ARB but I think it could make Dolphin almost shader stutterless. Besides, it is a modern language with broad support and with tools to convert it to HLSL, GLSL and MLSL. Cemu even has a optimization path which seems to give a decent performance boost.
It could ultimately simplify the shader generation code by using SpirvCross for the other backends.
Shaders in Dolphin are too simple for GLASM/ARB to even be necessary. In yuzu we used ARB mostly for experimenting, it is a fun project but with its own issues and downsides.
If any Dolphin dev sees around, what they can do is improve their SPIR-V Generation and do it directly without using glsl. You can use the library we use in yuzu:
https://github.com/ReinUsesLisp/sirit. The license is quite permissive so every can use it (including CEMU). Avoiding glslang and spir-v tools, saves a considerable amount of time on shader generation.