On 03/15/2013 05:33 PM, jupiter wrote:
Hi Brian,
On 3/15/13, Brian Paul<bri...@vmware.com> wrote:
On 03/15/2013 05:39 AM, jupiter wrote:
Thanks Brian and Matt.
On 3/15/13, Matt Turner<matts...@gmail.com> wrote:
On Thu, Mar 14, 2013 at 6:29 AM, Brian Paul<bri...@vmware.com> wrote:
Hmm, I guess autoconf still has some unneeded dependencies on DRI when
it's
not needed. You might try adding --with-gallium-drivers=swrast so that
no
DRI drivers are selected.
Don't think so. He's just not setting --with-gallium-drivers= so he
gets a radeon driver by default.
I did try to setup --with-gallium-drivers=llvm, it was an error, the
gallium drivers does not have llvm. I now changed to
--with-gallium-drivers=swrast. Matt is right, I don't need libdrm
anymore.
What is the correct llvm for --with-gallium-drivers? I also seen that
dri-core were also built, that could cause the problems.
The package built on CentOS 6.2 32-bit machine now included
lib/gallium, but the libGL.so and libGL.so.1 did not link to
lib/gallium/libGL.so.1.5.0. After manually linking the lib/libGL.so
and libGL.so.1 to lib/gallium/libGL.so.1.5.0, although the glxinfo
OpenGL rendering string is now pointing to the llvmpipe, but it seems
broken the xlib driver. It stopped running my 3D application via VNC
connection. Does the LLVMPIPE use any DRI?
No.
Or is it still xlib driver?
llvmpipe uses Xlib only.
As the VNC can only use xlib, anything bypass the xlib will break the
VNC connection.
Do other OpenGL apps run OK with llvmpipe or is it just Chimera that's
not working? How exactly is Chimera failing/broken?
Please see following benchmark for using both xlib and llvm:
(1) xlib driver
$ glxinfo | grep "OpenGL renderer string"
OpenGL renderer string: Mesa X11
glxgears 1500 FPS
glxspheres
15 frames/sec - 15 Mpixels/sec
(2) llvm driver
$ glxinfo | grep "OpenGL renderer string"
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.2, 128 bits)
glxgears: 600 FPS
glxspheres: 1 frames/sec - 1 Mpixels/sec
I'm not familiar with glxspheres. But the xlib/swrast driver was
optimized for simple things like glxgears. llvm might be slower on
that kind of thing, but it should be much, much faster with modern
apps that uses shaders and texturing.
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".
For your further examination, please see following configurations for
building each drivers:
(1) Compile xlib driver
${SOURCE}/${CONFIGURE} --prefix=${INSTALL} --enable-xlib-glx
--disable-dri --with-gallium-drivers=swrast
(2) Compile llvm driver
LLVM="/usr/local/libllvm/3.2"
${SOURCE}/${CONFIGURE} --prefix=${INSTALL} --enable-xlib-glx
--disable-dri --enable-gallium-llvm --with-gallium-drivers=swrast
--with-llvm-shared-libs=${LLVM}/lib --with-llvm-prefix=${LLVM}
Manually change libGL.so and libGL.so.1 to link lib/gallium/libGL.so.1.5.0.
Looks OK to me.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
