Shader packs can have extremely complex shader programs, resulting in shader compilation taking multiple seconds for many packs and as much as 20 seconds for the most complex packs. Currently, Iris compiles shader programs sequentially, waiting for one program to finish before compiling the next. This is very suboptimal.

At a minimum, Iris should dispatch all required glCompileShader invocations before starting to query the compilation status (which forces the compilation process for the queried shader to complete) and similar for the linking operations. This would require a sizable restructuring, especially on 1.17+ where we're working with code that's pretty highly intertwined with Minecraft's shader system in vanilla. However, on modern systems with many cores, it could make shader pack loading and settings changes many times faster, perhaps over an order of magnitude.

In addition, if that does not bring an improvement or if we want to not freeze Minecraft while waiting for shaders to compile, we might want to investigate https://github.com/KhronosGroup/OpenGL-Registry/blob/main/extensions/ARB/ARB_parallel_shader_compile.txt. Imagine if we could have an interactive loading bar displaying compile progress instead of the trusty old Minecraft (Not Responding) title bar?

Since Iris now also uses glsl-transformer for shader patching, it needs to be taken into consideration that glsl-transformer is not thread safe. However, in benchmarks shader patching has always been by a multiple faster than shader compilation. If parallel compilation is implemented, patching can be done sequentially, optionally in a separate thread, by creating a queue for patching jobs. When patch results are available, the compilation can be dispatched with each result. Since patching will be faster than compilation, even if a few threads are used this shouldn't be much of a problem.

Is there any particular reason why glsl-transformer isn't thread safe? I'd imagine that shader patching is oriented towards being done in a parallelizable way so that's surprising to hear.

There's a number of structures that work on a global level and would break if used concurrently. This could be avoided by carrying these around, but that hasn't been implemented because I expect it would complicate the API and cause additional memory overhead. (Also, it was faster to implement like this instead of splitting small bits of state out into tree-specific objects all over the place) There's no single or important reason why it isn't thread safe, but I haven't done that work yet and currently I don't know when that will be.

can you not use thread local?