Re: #define LP_MAX_THREADS 8

On 04/26/2013 07:11 AM, Brian Paul wrote:
> On 04/24/2013 02:24 PM, burlen wrote:
>> Hi,
>>
>> I've found that llvmpipe driver is capped at max of 8 threads. I'm
>> finding that to be a bit on the low side. for example I'm using
>> systems with much higher physical core counts, 16 is typical but a few
>> specialized smp's I use have as many as 1024 physical cores. Even my
>> workstation with 8 physical cores runs one of our opengl codes faster
>> up to about LP_NUM_THREADS=20. I had to tweak the define up to 32 for
>> testing. Any chance that the max could be increased, or better yet
>> could be optionally set to a larger value in the configure script?
>
> I think we could bump it up to 16.  I'll post a patch to the mesa-dev 
> list.  If you want to add a configure option, post your patch to the 
> mesa-dev list.
>
> I'm curious about what you're rendering.  Approximately how many 
> triangles and how large is the image?  What kind of shaders?
>
> Only the rasterization stage is parallelized in llvmpipe, not vertex 
> transformation, etc..  Apply Amdahl's law accordingly.
>
> -Brian
I appreciate your feedback, it's good to know about the limitations of 
threading, and how they're interacting with my choice of a test case! 
The code I used to test the threading options is a glsl implementation 
of surface lic, the run time for which is dominated by the fragment 
shaders when the input geometry is small, and by the vertext shaders 
when the input geometry is large. The timing I made used a very small 
dataset from our regression tests, 10s -100s of triangles, but has a few 
hundred fragment shader iterations. That probably explains why the 
threading faired so well. Our real datasets have quite a bit more 
geometry, the larger ones I've seen have 100-500 million quads. It will 
be interesting to see how much of an impact threading has processing 
these larger datasets.

Burlen