[Mesa-dev] glxgears is faster but 3D render is so slow
jupiter.hce at gmail.com
Mon Mar 25 03:59:03 PDT 2013
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
>>>> 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
>>>> 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?
I've tried to define LP_NUM_THREADS=10, but does not work. 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.
More information about the mesa-dev