[Mesa-dev] Thoughts about threading the GLSL compiler

[Ian Romanick]

The topic of improving application load time by running the GLSL
compiler in a separate thread for each call to glCompileShader (or
glLinkProgram).  Eric had done some experiments with this before (is
there a branch somewhere?), and he found that it wasn't a win because
programs regularly do

	glCompileShader(sh, ...);
	glGetShaderiv(sh, GL_COMPILE_STATUS);

Calling glGetShaderiv effectively blocked waiting for the compiler
thread to finish.

I think there's a slight modification of the "obvious" technique that
allows a simple implemenation and improved performance for applications
like the above sample.  The compiler thread generates three things that
the application can use, and each of these is generated at a different
time by a different part of the stack.

1. The compile status: the common front-end.

2. The info log: the common front-end and possibly the driver (e.g.,
performance warnings when debug is enabled).

3. The executable program: the driver.

Each of these are also used at different times.  The compile status is
often used immediately, and the executable program isn't used until
sometime later.  Producing the executable program is the thing that we
want to accelerate, and a lot of the time spent to produce that happens
deep in the driver (e.g., register allocation).

We ought to be handle this by having a condition variable per program
and a "ready" flag for each of compile status, info log, and executable.
 The consumers can just wait on the condition variable, and the producer
can just wait on the condition varible and the ready-flag become true.
This will allow us to get GL_COMPILE_STATUS without having to wait for
register allocation.

Thoughts?