[Mesa-dev] [PATCH 00/21] deferred and threaded glCompileShader
idr at freedesktop.org
Fri May 2 11:03:56 PDT 2014
I reviewed and pushed patch 1.
I sent some comments about patches 2, 3, and 20.
I want to look at 19 a bit more, and I'd also really like to have Eric
review it... since he wrote a pretty similar thing 18 months ago.
Patches 4 through 15, the "fixed" 16, 17, and 18 are
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
On 04/22/2014 01:58 AM, 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
> 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
> 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 at lists.freedesktop.org
More information about the mesa-dev