On Tuesday 22 April 2014, Chia-I Wu wrote:
> Hi list,
> 
> This series adds a thread pool to the GLSL compiler, and a drirc option to
> defer glCompileShader calls to the pool.  The goal is to reduce the start-up
> time of applications that are aware of this feature.  That is, applications
> that compile shaders first and check the compile status later.
> 
> I do not have numbers from real applications yet.  But trying to compiling a
> set of 2882 shaders extracted from some trace file, with everything else
> idled, the time it takes is
> 
>   8 threads: 17.8s
>   4 threads: 20.3s
>   2 threads: 31.2s
>   1 threads: 58.0s
>   no thread pool: 54.5
> 
> on a quad core system.
> 
> Patches 1-4 fix potential races in the GLSL compiler.  As the compiler is
> already shared by all contexts, these patches could be desirable even without
> the thread pool that I am going to add.
> 
> Patches 5-18 adds true GL_DEBUG_OUTPUT_SYNCHRONOUS support to the KHR_debug
> code.  All except patch 18 are clean-ups.  Patch 18 adds a mutex to protect
> gl_debug_state.
> 
> Patch 19 defines a simple API to create and work with thread pools, as well as
> a test for the API.
> 
> Patch 20 adds the singleton GLSL thread pool and allows glCompileShader to be
> deferred to the pool.  This feature needs to be explicitly enabled with
> _mesa_enable_glsl_threadpool.
> 
> Patch 21 adds a drirc option to enable the thread pool.  The idea is that only
> applications that can benefit from it will enable it.

If applications are supposed to enable this behavior themselves I think
it would be better to add an extension that lets them do:

glEnable(GL_DEFERRED_SHADER_COMPILATION_EXT);

The drirc option can still be useful for overriding the default though.

Fredrik

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev