[Mesa-dev] glxgears is faster but 3D render is so slow

[Brian Paul]

On 03/25/2013 04:59 AM, jupiter wrote:
> Hi Brian,
>
> On 3/22/13, Brian Paul<brianp at vmware.com>  wrote:
>> On 03/21/2013 03:51 AM, jupiter wrote:
>>> Hi Brian,
>>>
>>> On 3/21/13, Brian Paul<brianp at vmware.com>   wrote:
>>>> On 03/20/2013 04:07 AM, jupiter wrote:
>>>>> Hi Brian,
>>>>>
>>>>> On 3/19/13, Brian Paul<brianp at vmware.com>    wrote:
>>>>>>> It is fair to say, if running llvm driver in my local machine (a
>>>>>>> 32-bit CentOS 6.2 without VNC connection), it was indeed faster than
>>>>>>> the xlib driver.
>>>>>>>
>>>>>>> Seems to me that the llvm driver broken the xlib VNC connection which
>>>>>>> could be caused by either I haven't configure the llvm correctly, or
>>>>>>> mesa llvm compile process may have bugs.
>>>>>>
>>>>>> I don't understand what you mean by "llvm driver broken the xlib VNC
>>>>>> connection".
>>>>>
>>>>> I have tested llvm driver in two platforms:
>>>>>
>>>>> (1) A local computer running on CentOS 6.2 which does not have
>>>>> hardware acceleration, but I can directly access it. The llvm driver
>>>>> is indeed much faster than the swrast, I could run an  application
>>>>> with 3D structure rotation.
>>>>>
>>>>> (2) A virtual machine running on CentOS 6.2, I have to access it via
>>>>> VNC. I was not able to run the 3D application, the graphic jerky and
>>>>> could not respond. If I changed to run swrast, the 3D application
>>>>> graphic could be run much smoothly and response was normal, but the 3D
>>>>> rotation was stopped because it was too slower to rotate the 3D
>>>>> structure.
>>>>>
>>>>> That was what I mean the llvm broken the xlib VNC connection. Have you
>>>>> tested the llvm driver in VNC connection?
>>>>
>>>> No, I haven't.  I'm really not sure what's happening in this
>>>> situation.  My only totally wild guess is there's competition between
>>>> the VNC server and Mesa for CPU time.  The llvmpipe driver is threaded
>>>> and creates as many threads as there are CPU cores.  You can set the
>>>> LP_NUM_THREADS to tell llvmpipe how many threads to use (0 for no
>>>> threading).  How many CPU cores do you have?
>>>
>>> The virtual machine I tested has only one CPU, but we can make it more
>>> cups if it helps. I'll try to set up LP_NUM_THREADS tomorrow, but I
>>> don't expect it caused the problem. One thing I have to address is
>>> that xlib swrast is running very well in VNC connection despite it is
>>> too slower to do 3D structure rotation. May be you can look at the
>>> difference between the xlib LLVM driver and xlib swrast driver.
>>
>> The drivers are totally different, but underneath both they render
>> into shared X images which are then copied to the on-screen window
>> during glXSwapBuffers.  That code is pretty much the same.
>>
>> I don't know what else would account for the difference you're seeing.
>>
>>
>>> I'll be happy to help testing or debugging llvm driver on VNC
>>> connection if you are going to resolve the issues seriously and if you
>>> can tell me the procedure and data collection you need.
>>
>> I'm just way too busy right now to dig into this.  Hopefully you can
>> make some progress playing with virtual CPUs and LP_NUM_THREADS.
>>
>
> I guess to define LP_NUM_THREADS as an environment variable, correct?

Yes.


> I've tried to define LP_NUM_THREADS=10, but does not work.

The limit is currently 8.  If your VM only has one CPU core, then 
llvmpipe will automatically set num_threads = 1 and increasing it with 
LP_NUM_THREADS won't accomplish much.


> I'll try it
> again it I was wrong. Otherwise, let me know if I can help for testing
> on the virtual machine when you are available to try the debug.

Can you try increasing the number of cores in your VM?  But like I 
said above, that's just a wild guess for something to try.

-Brian