I don't think this will work in general, the 16bit extensions aren't available everywhere and we can't actually support a backend that uses GLES and has 16bit uniform values, as the bindings will be incorrect.

16bit uniform buffer access is part of Vulkan 1.1 core, so this work on all of our targets. However, there are a few subproblems that I don't have time to work through right now: flutter/flutter#128836

TIL.

we use the same generated headers on GLES and Vulkan though, so we'd need to solve that issue too - probably generate a different set of bindings assuming 32bit and 16bit float and select at runtime.

we use the same generated headers on GLES and Vulkan though

Just for Android, right? On MacOS, I think we end up using the Metal headers for all of the backends, which maybe is another problem that needs to be solved. :/

I'm still not really sure what the best design approach would be for reconciling the different backend headers. Maybe we can automate the common case and create a generic lowest common denominator meta-header with special UBO/VBO builders to dispatch the specific packing behavior of the backend in use. But importantly, using this is optional, and we can still use the per-backend struct directly for special backend-specific optimizations whenever there's a need.

Actually, we can probably further avoid this problem by just finishing our implementation of 16 bit uniform access for the other backends. Even if we can't use 16 bit uniforms on GLES 2 devices, we still just enumerate and pull each uniform out of the buffer on the CPU, and so we can emulate it.

So if we invest some time in fixing the GLES and Vulkan incompatibilities, we might be able to continue getting away with sharing headers for multiple backends. (FYI @chinmaygarde)

Added another issue for GLES here: flutter/flutter#128881