On Tue, 2014-04-22 at 16:58 +0800, 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.
I've skimmed over patches 5-17 looks like some good clean ups. I've made some comments for patch 12 and 16. > > 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. > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev