On 03/25/2013 04:59 AM, jupiter wrote:
Hi Brian,
On 3/22/13, Brian Paul<bri...@vmware.com> wrote:
On 03/21/2013 03:51 AM, jupiter wrote:
Hi Brian,
On 3/21/13, Brian Paul<bri...@vmware.com> wrote:
On 03/20/2013 04:07 AM, jupiter wrote:
Hi Brian,
On 3/19/13, Brian Paul<bri...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
