Suggestion: Use glslang to compile shaders

[AntonPieper]

Compiling the shaders using glslang would unify error messages across all devices and enable all GLSL language features (like #line) for all devices (by using SPIR-V and glShaderBinary). The library would need to be compiled which takes some time, but would only need to be done once every time the glslang version would be updated. When building glslang on my phone, these are the different static library sizes (not all are needed):

288K    External/spirv-tools/source/diff/libSPIRV-Tools-diff.a
3.5M    External/spirv-tools/source/libSPIRV-Tools.a
140K    External/spirv-tools/source/link/libSPIRV-Tools-link.a
220K    External/spirv-tools/source/lint/libSPIRV-Tools-lint.a
9.4M    External/spirv-tools/source/opt/libSPIRV-Tools-opt.a
636K    External/spirv-tools/source/reduce/libSPIRV-Tools-reduce.a
1.2M    SPIRV/libSPIRV.a
340K    SPIRV/libSPVRemapper.a
4.0K    glslang/OSDependent/Unix/libOSDependent.a
24K     glslang/libGenericCodeGen.a
4.9M    glslang/libMachineIndependent.a
60K     glslang/libglslang-default-resource-limits.a
56K     glslang/libglslang.a

Is this something of interest, or is the vendor-specific error reporting and language support "good enough"?

[markusfisch]

It's certainly interesting! But currently I see more disadvantages than advantages. For example, building the native library for all architectures means a not inconsiderable complication. Then, using this library would mean an abstraction of the features that are actually available, which will of course break somewhere.

So for me, the vendor-specific error reporting and language support is indeed good enough at this time.

[AntonPieper]

I will close this as not planned for now. The main advantage of glslang would be a common shader format that should work on all devices equally (common binary format) since GLES ≥ 2.0 and that the implementation would compile the program regardless of GPU driver. The additional native code would increase the complexity of the build system, though. Android studio can hide most of it though by having a good CMake integration and running that external build system through Gradle (for all architectures) automatically, but the split between managed java code and unmanaged C/C++ code remains