On 06/01/2016 05:19 AM, Marek Olšák wrote: > On Fri, May 27, 2016 at 8:49 PM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: >> Hello. >> >> http://en.cppreference.com/w/cpp/thread/future >> http://en.cppreference.com/w/cpp/thread/async >> >> Assumption: Shader compilation will need run on separate thread(s). >> >> From a certain perspective, one of the easy ways of removing Mesa shader >> compilation from the "main" thread would be to use std::future for some >> fields in struct gl_program (defined in mtypes.h) and in related source >> code. > > Your perspective is completely wrong. First, you need to understand > why shader compilation speed is a problem for some apps and when you > do, you'll realize there is only one solution and this is not it. I'll > let you figure it out by yourself.
I think this is unnecessarily dismissive. Parallel shader compilation is a big deal. Every other GL driver implements it to one degree or another. Khronos has standardized a method to interact with it better (GL_ARB_parallel_shader_compile). Valve has put a lot of effort into teaching other game developers how to not "defeat" it. Compilation caches are, without any doubt, the 90% solution. This coupled with mis-coded applications has generally been our argument against spending time implementing parallel compilation. The mis-coded application problem is gradually fading into history. Heck, I think most applications don't even bother to check compile or link status in release builds! Either way, there are still a number of important cases that a shader cache cannot help. 1. First run of an application still takes too long. I regularly hear developers complain that if the first run of a game takes too long to start, many people will give up before even playing. This is more a problem for mobile games, but I hear the same thing from other developers. 2. Driver updates generally invalidate a shader cache. This results in long load times at somewhat unpredictable times. It also creates a negative feedback loop where users don't want to update their driver because they don't want to wait an extra 10 minutes for a game to load that they're only going to play for 5 minutes. 3. Similar to #2, application updates generally invalidate a shader cache because they include new shaders. 4. Similar to #3, application developers generally don't get much benefit from a shader cache while developing their application. It is especially painful for them because they tend to have the beefiest, highest thread count CPUs... and they know enough to know that those threads are sitting idly by. If nothing else, compilation of multiple compilation units is embarrassingly parallel. None of us would ever consider using a build system that didn't use all the available processing power in our system. The whole notion is just silly. Even though ccache exists, we still use 'make -j99', distcc, and icecream. It's also tempting to think that having SPIR-V in OpenGL will solve these problems, but that is unlikely. There are a lot of applications in the pipeline that, obviously, don't use SPIR-V in OpenGL. A SPIR-V solution for end users would still be years away even if we shipped SPIR-V support tomorrow. In addition, whenever we look at a profile of compilation time, almost all of the time is in the backend doing register allocation and instruction scheduling. SPIR-V will do nothing for that. A shader cache allows us to avoid the work, and parallel compilation makes it faster in the cases that cannot be avoided. While I believe that there are still more important things to work on, I would not oppose someone else working on parallel shader compilation. I don't think there was any opposition when Chia-I Wu started working on it a couple years ago (patch series starting with https://patchwork.freedesktop.org/patch/32146/). Everyone was just too busy to review his patches, and he moved on to other things. > tl;dr Understand the problem before you propose a solution. > > Marek > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
