On Tue, May 6, 2014 at 5:27 AM, Fredrik Höglund <fred...@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 > -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev