[Mesa-dev] Parallel shader compilation (was Re: Discussion: C++11 std::future in Mesa)

[Ian Romanick]

On 06/01/2016 05:19 AM, Marek Olšák wrote:
> On Fri, May 27, 2016 at 8:49 PM, ⚛ <0xe2.0x9a.0x9b at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev