[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mesa3d-dev
Subject:    Re: [Mesa-dev] [PATCH 00/21] deferred and threaded glCompileShader
From:       Chia-I Wu <olvaffe () gmail ! com>
Date:       2014-05-06 8:42:10
Message-ID: CAPaKu7R=8KvoWMGu1uH3Y8Gmr-iy4Jx5+wtwFhuW41VN3nY6Jw () mail ! gmail ! com
[Download RAW message or body]

On Tue, May 6, 2014 at 5:27 AM, Fredrik Höglund <fredrik@kde.org> wrote:
> 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);
glHint might be better.  But it is hard to define the behavior of
deferred shader compilation without restricting what an implementation
may do.  And for a driver that is able to determine GL_COMPILE_STATUS
quickly and defer only the optimization passes, threaded compile may
be always on.


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



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

[prev in list] [next in list] [prev in thread] [next in thread]