Re: [Mesa-dev] glxgears is faster but 3D render is so slow
Hi Brian, On 3/26/13, Brian Paul bri...@vmware.com wrote: 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. I'll try it multiple cores and will let you know the results. Kind regards. Jupiter -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
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 Paulbri...@vmware.com wrote: On 03/20/2013 04:07 AM, jupiter wrote: Hi Brian, On 3/19/13, Brian Paulbri...@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? 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. Kind regards, Jupiter -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
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 Paulbri...@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.
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.
(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.
One more question, how can I build llvm without manually changing the
libGL.so link? Was I missing something in my compilation? Or is there
any issue in mesa build and installation process?
I think that's a deficiency in our configure/install system. I
haven't looked into it though.
Good to know.
Thanks Brian,
Kind regards.
Jupiter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
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?
(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.
One more question, how can I build llvm without manually changing the
libGL.so link? Was I missing something in my compilation? Or is there
any issue in mesa build and installation process?
Thanks.
Kind regards.
Jupiter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
Hi Brian,
On 3/19/13, Brian Paul bri...@vmware.com wrote:
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.
Cannot run GL application using llvm driver via VNC. I'll change to a
faster network and test it again, will let you know tomorrow.
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.
Thanks for the confirmation.
Kind regards.
Jupiter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
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? Or is it still xlib driver? As the VNC can only use xlib, anything bypass the xlib will break the VNC connection. Thank you. Kind regards. Jupiter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
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 Turnermatts...@gmail.com wrote:
On Thu, Mar 14, 2013 at 6:29 AM, Brian Paulbri...@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
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.
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.
Thank you.
Kind regards,
Jupiter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
Hi Brian,
On 3/14/13, Brian Paul bri...@vmware.com wrote:
On 03/13/2013 04:11 AM, jupiter wrote:
Hi Brian,
Sorry for not being clear, let me clarify it.
On 3/13/13, Brian Paulbri...@vmware.com wrote:
Well, the Xlib/swrast driver does everything in software, unlike a DRI
driver which does most things with the GPU. Xlib will always be slower.
My local test machine graphic card does not have hardware
acceleration, it does not support OpenGL, it does not have NVIDIA. I
guess the DRI driver may still implement software GL even though it
might access some basic functions of the low budget graphic card, but
correct me, if I am using wrong terminology.
Yes, swrast may also be used via DRI, when there's no DRI driver for
the hardware GPU or when the hardware driver needs a software fallback.
The gallium llvmpipe driver should be quite a bit faster.
Just install LLVM first, then reconfigure/rebuild Mesa, set your
LD_LIBRARY_PATH to the lib/gallium/ directory and you should get
llvmpipe.
Yes, I have already built the Mesalib with LLVM, I posted the
configuration in my last email, let me post it again.
${SOURCE}/${CONFIGURE} --prefix=${INSTALL} --enable-xlib-glx
--disable-dri --enable-gallium-llvm --with-llvm-shared-libs
It did not produce a faster result, it was virtually not much
differences when I run Chimera comparing to use of
--with-gallium-drivers=swrast unless my configuration is wrong. Please
let me know a correct version of configuration for llvmpipe. The
libdrm version is 2.4.42. The libllvm version is 3.2.
libdrm is irrelevant for llvmpipe.
I know it should not include the libdrm, but I could not compile the
mesa without libdrm, please see following error. How to resolve that
issue?
checking for clock_gettime in -lrt... yes
checking for posix_memalign... yes
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... no
configure: Shared GLAPI is only useful for DRI, disabling
checking for LIBDRM... yes
checking for X11... yes
checking for XLIBGL... yes
checking for mincore... yes
checking for LIBUDEV... no
checking for XCB_DRI2... yes
checking for llvm-config... /usr/local/libllvm/3.2/bin/llvm-config
checking for RADEON... configure: error: Package requirements
(libdrm_radeon = 2.4.42) were not met:
Requested 'libdrm_radeon = 2.4.42' but version of libdrm_radeon is 2.4.33
I don't know there it coms from, my graphic card is 00:02.0 VGA
compatible controller: Intel Corporation Mobile GM965/GL960 Integrated
Graphics Controller (primary) (rev 03)
I have also add libxcbproto and libxcb to the LD_LIBRARY_PATH as
requested the libraries versions in CentOS 6.2 is newer than the
system installed.
I can also use a test program to measure Mesa in different drivers if
you could let me know which test program can be used for benchmarking
the Mesalib using different drivers of swrast, or llvm or DRI? And
where is the test program source code I can download from?
The Mesa demos git tree can be cloned per
http://www.mesa3d.org/repository.html
Please also see attached glxinfo for Mesa llvm.
The key line is OpenGL renderer string: Mesa X11. That's not
llvmpipe. If you're really using llvmpipe it should say something
like OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.2, 128
bits).
Perhaps your LD_LIBRARY_PATH env is pointing at the wrong libGL.so
Hmm, the LD_LIBRARY_PATH seems set properly.
$ echo $LD_LIBRARY_PATH
/usr/local/mesallvm/9.1/lib:/usr/local/libllvm/3.2/lib
I also changed to following configure:
${SOURCE}/${CONFIGURE} --prefix=${INSTALL} --enable-xlib-glx
--disable-dri --enable-gallium-llvm --with-llvm-shared-libs
--with-llvm-prefix=/usr/local/libllvm/3.2
$ make
$ make install
But still not luck, could not get OpenGL renderer string to llvm, nor
can find Gallium .
$ glxinfo | grep -i LLVM
$ glxinfo | grep -i Gallium
Nothing coming.
Are there anything missing or setting wrong in above configure? Could
you please give me a correct configuration?
Thanks.
Kind regards,
Jupiter
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
Hi Brian,
Sorry for not being clear, let me clarify it.
On 3/13/13, Brian Paul bri...@vmware.com wrote:
Well, the Xlib/swrast driver does everything in software, unlike a DRI
driver which does most things with the GPU. Xlib will always be slower.
My local test machine graphic card does not have hardware
acceleration, it does not support OpenGL, it does not have NVIDIA. I
guess the DRI driver may still implement software GL even though it
might access some basic functions of the low budget graphic card, but
correct me, if I am using wrong terminology.
The gallium llvmpipe driver should be quite a bit faster.
Just install LLVM first, then reconfigure/rebuild Mesa, set your
LD_LIBRARY_PATH to the lib/gallium/ directory and you should get llvmpipe.
Yes, I have already built the Mesalib with LLVM, I posted the
configuration in my last email, let me post it again.
${SOURCE}/${CONFIGURE} --prefix=${INSTALL} --enable-xlib-glx
--disable-dri --enable-gallium-llvm --with-llvm-shared-libs
It did not produce a faster result, it was virtually not much
differences when I run Chimera comparing to use of
--with-gallium-drivers=swrast unless my configuration is wrong. Please
let me know a correct version of configuration for llvmpipe. The
libdrm version is 2.4.42. The libllvm version is 3.2.
I can also use a test program to measure Mesa in different drivers if
you could let me know which test program can be used for benchmarking
the Mesalib using different drivers of swrast, or llvm or DRI? And
where is the test program source code I can download from?
Please also see attached glxinfo for Mesa llvm.
Thank you.
Kind regards,
Jupiter
-Brian
On 03/12/2013 07:37 AM, jupiter wrote:
Hi Brian,
You are right, setting MESA_GLX_DEPTH_BITS to 24 bit does not change
anything. So why Xlib has such poor performance to run following
application?
http://www.cgl.ucsf.edu/chimera/download.html
Are there any other things I can try to make Xlib driver performance
equals to DRI?
Thank you.
Kind regards,
Jupiter
On 3/12/13, Brian Paulbri...@vmware.com wrote:
I don't think you have to worry about the difference in buffer depths.
If you really want a 24-bit depth buffer you can do 'export
MESA_GLX_DEPTH_BITS=24'
-Brian
On 03/09/2013 12:48 AM, jupiter wrote:
Hi Brian,
Please see attached config.log. Le me make a correction, I mean 32
buffer bit and 24 depth bit in DRI and 24 buffer bit and 16 bit depth
bit in xlib driver. Will it make difference if setting 32 buffer bit
and 24 depth bit for xlib? If so, how to do it?
Thank you.
Kind regards.
Jupiter
On 3/8/13, jupiterjupiter@gmail.com wrote:
Hi Brian,
I finally built Mesa with configuration --enable-xlib-glx
--disable-dri --enable-gallium-llvm --with-llvm-shared-libs, with
dependencies of llvm and drm. It does not work either, please see
following glxinfo. Please let me know if my configuration is not
correct, or if there are any other ways I can try to make it work.
$ glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: Brian Paul
server glx version string: 1.4 Mesa 9.1-devel
server glx extensions:
GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
GLX_MESA_release_buffers, GLX_ARB_get_proc_address,
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info,
GLX_EXT_visual_rating,
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer
client glx vendor string: Brian Paul
client glx version string: 1.4 Mesa 9.1-devel
client glx extensions:
GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
GLX_MESA_release_buffers, GLX_ARB_get_proc_address,
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info,
GLX_EXT_visual_rating,
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer
GLX version: 1.4
GLX extensions:
GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
GLX_MESA_release_buffers, GLX_ARB_get_proc_address,
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info,
GLX_EXT_visual_rating,
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer
OpenGL vendor string: Brian Paul
OpenGL renderer string: Mesa X11
OpenGL version string: 2.1 Mesa 9.1-devel
OpenGL shading language version string: 1.20
OpenGL extensions:
GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra,
GL_EXT_blend_color,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture,
GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object,
GL_EXT_vertex_array, GL_EXT_compiled_vertex_array,
GL_EXT_texture,
GL_EXT_texture3D, GL_IBM_rasterpos_clip,
GL_ARB_point_parameters,
GL_EXT_draw_range_elements, GL_EXT_packed_pixels,
GL_EXT_point_parameters,
GL_EXT_rescale_normal, GL_EXT_separate_specular_color,
GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap,
GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp,
GL_SGIS_texture_lod, GL_ARB_multitexture,
GL_IBM_multimode_draw_arrays
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
Hi Brian, You are right, setting MESA_GLX_DEPTH_BITS to 24 bit does not change anything. So why Xlib has such poor performance to run following application? http://www.cgl.ucsf.edu/chimera/download.html Are there any other things I can try to make Xlib driver performance equals to DRI? Thank you. Kind regards, Jupiter On 3/12/13, Brian Paul bri...@vmware.com wrote: I don't think you have to worry about the difference in buffer depths. If you really want a 24-bit depth buffer you can do 'export MESA_GLX_DEPTH_BITS=24' -Brian On 03/09/2013 12:48 AM, jupiter wrote: Hi Brian, Please see attached config.log. Le me make a correction, I mean 32 buffer bit and 24 depth bit in DRI and 24 buffer bit and 16 bit depth bit in xlib driver. Will it make difference if setting 32 buffer bit and 24 depth bit for xlib? If so, how to do it? Thank you. Kind regards. Jupiter On 3/8/13, jupiterjupiter@gmail.com wrote: Hi Brian, I finally built Mesa with configuration --enable-xlib-glx --disable-dri --enable-gallium-llvm --with-llvm-shared-libs, with dependencies of llvm and drm. It does not work either, please see following glxinfo. Please let me know if my configuration is not correct, or if there are any other ways I can try to make it work. $ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: Brian Paul server glx version string: 1.4 Mesa 9.1-devel server glx extensions: GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer client glx vendor string: Brian Paul client glx version string: 1.4 Mesa 9.1-devel client glx extensions: GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer GLX version: 1.4 GLX extensions: GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer OpenGL vendor string: Brian Paul OpenGL renderer string: Mesa X11 OpenGL version string: 2.1 Mesa 9.1-devel OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object, GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters, GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_ARB_multitexture, GL_IBM_multimode_draw_arrays, GL_IBM_texture_mirrored_repeat, GL_3DFX_texture_compression_FXT1, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_secondary_color, GL_EXT_texture_env_add, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_INGR_blend_func_separate, GL_MESA_resize_buffers, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_SUN_multi_draw_arrays, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_EXT_framebuffer_object, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_MESA_window_pos, GL_NV_packed_depth_stencil, GL_NV_texture_rectangle, GL_ARB_depth_texture, GL_ARB_occlusion_query, GL_ARB_shadow, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_window_pos, GL_ATI_envmap_bumpmap, GL_ATI_fragment_shader, GL_EXT_stencil_two_side, GL_EXT_texture_cube_map, GL_NV_depth_clamp, GL_NV_point_sprite, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_shader_objects, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_EXT_depth_bounds_test, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_ARB_depth_clamp, GL_ARB_fragment_program_shadow, GL_ARB_half_float_pixel, GL_ARB_occlusion_query2, GL_ARB_point_sprite, GL_ARB_shading_language_100, GL_ARB_sync, GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
Hi Brian,
Sorry I spoke too earlier. I have double checked, there was a gallium
in build directory, but when I ran make install the system seems
copied the gallium/libGL.so.1.5.0 to the installation directory
mesa/lib//libGL.so.1.5.0, and the symblic link libGL.so -
libGL.so.1.5.0.
I think it is fine. The only thing I see differences when I compare
glxinfo from mesa DRI and mesa xlib are buffer size and depth buffer
size. In mesa DRI the buffer size is 32, depth buffer size is 24, but
in mesa xlib driver the buffer size is 24 and depth buffer size is 16.
Will this impacts the 3D in xlib driver? How can configure mesa to get
32 buffer size and 24 depth size for xlib driver?
Please see following my configuration:
${SOURCE}/${CONFIGURE} --prefix=${INSTALL} --enable-xlib-glx
--disable-dri --enable-gallium-llvm --with-llvm-shared-libs
Thank you.
Kind regards.
Jupiter
On 3/9/13, Brian Paul bri...@vmware.com wrote:
On 03/08/2013 02:22 PM, jupiter wrote:
Hi Brian,
Make sure you're using the libGL.so found in mesa/lib/gallium/
There is no gallium in my mesalib/lib. What could be wrong here?
Hmm, not sure. Did you do 'make clean' before you configured Mesa?
I actually double checked, the
Maybe post your config.log file.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
Hi, It seems using xlib-glx stopped 3D rotating. If I built mesa 9.1 using DRI in my local machine, it can rotate 3D picture. Is there anyway workaround to use xlib-glx for 3D applications? Thank you. Kind regards. J Hi, I built mesa 9.1 with following configuration: --enable-xlib-glx --disable-dri --with-gallium-drivers=swrast --enable-osmesa --with-osmesa-bits=32 The mesa package is used by TurboVNC, so xlib glx has to be used instead of DRI. It works well to gain faster speed in glxgears, but it has huge problems to render a 3D modules in an application of CHIMERA. The thing puzzled me is when I use CentOS system provided Mesa 7.11, the CHIMERA 3D picture rotation works fine despite the glxgears is very slow (250 FPS). I am not clear that the slower 3D rendering in my built mesa is because the DRI or I may miss some configurations. Appreciate any advice. Thank you. Kind regards. Jupiter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
, GL_NV_conditional_render, GL_ARB_debug_output, GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location, GL_ARB_fragment_coord_conventions, GL_ARB_provoking_vertex, GL_ARB_sampler_objects, GL_EXT_provoking_vertex, GL_ARB_get_program_binary, GL_ARB_robustness, GL_ARB_texture_storage, GL_ARB_invalidate_subdata 32 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x21 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x22 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x93 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x94 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x95 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x96 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x97 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x98 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x99 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x9a 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x9b 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x9c 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x9d 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x9e 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x9f 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa0 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa1 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa2 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa3 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa4 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa5 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa6 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa7 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa8 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa9 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xaa 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xab 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xac 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xad 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xae 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xaf 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x62 32 tc 0 32 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None On 3/8/13, Brian Paul bri...@vmware.com wrote: What does 'glxinfo' say with this configuration? I'm guessing you're using the softpipe driver which is meant for correctness, not speed. For speed, you want the llvmpipe driver. Install LLVM on your system first then reconfigure/rebuild Mesa. -Brian On 03/07/2013 04:58 AM, jupiter wrote: Hi, It seems using xlib-glx stopped 3D rotating. If I built mesa 9.1 using DRI in my local machine, it can rotate 3D picture. Is there anyway workaround to use xlib-glx for 3D applications? Thank you. Kind regards. J Hi, I built mesa 9.1 with following configuration: --enable-xlib-glx --disable-dri --with-gallium-drivers=swrast --enable-osmesa --with-osmesa-bits=32 The mesa package is used by TurboVNC, so xlib glx has to be used instead of DRI. It works well to gain faster speed in glxgears, but it has huge problems to render a 3D modules in an application of CHIMERA. The thing puzzled me is when I use CentOS system provided Mesa 7.11, the CHIMERA 3D picture rotation works fine despite the glxgears is very slow (250 FPS). I am not clear that the slower 3D rendering in my built mesa is because the DRI or I may miss some configurations. Appreciate any advice. Thank you. Kind regards. Jupiter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxgears is faster but 3D render is so slow
, GL_EXT_separate_shader_objects, GL_EXT_texture_swizzle, GL_EXT_vertex_array_bgra, GL_NV_conditional_render, GL_ARB_debug_output, GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location, GL_ARB_fragment_coord_conventions, GL_ARB_provoking_vertex, GL_ARB_sampler_objects, GL_EXT_provoking_vertex, GL_ARB_get_program_binary, GL_ARB_robustness, GL_ARB_texture_storage, GL_ARB_invalidate_subdata 32 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x21 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x22 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x93 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x94 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x95 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x96 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x97 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x98 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x99 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x9a 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x9b 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x9c 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x9d 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x9e 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x9f 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa0 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa1 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa2 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa3 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa4 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa5 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa6 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa7 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa8 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xa9 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xaa 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xab 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xac 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xad 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xae 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0xaf 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x62 32 tc 0 32 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None Thank you. Kind regards. Jupiter On 3/8/13, jupiter jupiter@gmail.com wrote: Hi Brian, Thanks for your response, please see following glxinfo. I am currently building the LLVM, seems need hours to complete it. Is it correct to reconfigure/rebuild Mesa with --enable-xlib-glx --disable-dri --enable-gallium-llvm --with-llvm-shared-libs? $ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: Brian Paul server glx version string: 1.4 Mesa 9.1-devel server glx extensions: GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer client glx vendor string: Brian Paul client glx version string: 1.4 Mesa 9.1-devel client glx extensions: GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer GLX version: 1.4 GLX extensions: GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer OpenGL vendor string: Brian Paul OpenGL renderer string: Mesa X11 OpenGL version string: 2.1 Mesa 9.1-devel OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object, GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters, GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_texture_edge_clamp
[Mesa-dev] glxgears is faster but 3D render is so slow
Hi, I built mesa 9.1 with following configuration: --enable-xlib-glx --disable-dri --with-gallium-drivers=swrast --enable-osmesa --with-osmesa-bits=32 The mesa package is used by TurboVNC, so xlib glx has to be used instead of DRI. It works well to gain faster speed in glxgears, but it has huge problems to render a 3D modules in an application of CHIMERA. The thing puzzled me is when I use CentOS system provided Mesa 7.11, the CHIMERA 3D picture rotation works fine despite the glxgears is very slow (250 FPS). I am not clear that the slower 3D rendering in my built mesa is because the DRI or I may miss some configurations. Appreciate any advice. Thank you. Kind regards. Jupiter ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa-8.0.2 libGL.so: undefined reference to `XGetXCBConnection'
On 2012-04-18 23:36+1000, jupiter@gmail.com wrote: I ran make linux-dri-x86 and make install, sorry, I thought I put the commands in response. As I said, I followed online document of Compiling and Installing. Unless I was missing something from the document, I guess there is no need to manually run configure to link libX11-xcb and libxcb-glx, correct? It has been resolved after adding x11-xcb and xcb-glx to linux-dri. Did I use a wrong config file linux-dri-x86 to build the Mesa on CentOS 6 and Intel CPU T5550? Anyway, thank you very much. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa-8.0.2 libGL.so: undefined reference to `XGetXCBConnection'
On 2012-04-18 09:48-0400, Adam Jackson wrote: On Tue, 2012-04-17 at 23:53 +1000, jupiter@gmail.com wrote: On 2012-04-17 09:34-0400, Adam Jackson wrote: Note that neither one of the above libraries is mentioned in your ldd output, which means libGL was linked incorrectly. What method did you use to build Mesa? The default of the configuration was used. How should I change the default configure to link libX11-xcb and libxcb-glx properly? That's not the answer I was looking for. When I ask what method did you use I expect a reply more like: I ran ./configure and then make or: I ran 'make linux-dri-x86' I ran make linux-dri-x86 and make install, sorry, I thought I put the commands in response. As I said, I followed online document of Compiling and Installing. Unless I was missing something from the document, I guess there is no need to manually run configure to link libX11-xcb and libxcb-glx, correct? Thank you. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa-8.0.2 libGL.so: undefined reference to `XGetXCBConnection'
Thanks Adam, please see following information. On 2012-04-17 09:34-0400, Adam Jackson wrote: On Mon, 2012-04-16 at 22:15 +1000, jupiter@gmail.com wrote: I've just built Mesa-8.0.2 in a Linux box. Then there were errors of libGL.so: undefined reference to `XGetXCBConnection' % nm -aD --defined /usr/lib/libX11-xcb.so.1 | grep XCB 473ef560 T XGetXCBConnection $ nm -aD --defined /usr/lib/libX11-xcb.so.1 | grep XCB 0470 T XGetXCBConnection and libGL.so: undefined reference to `xcb_glx_client_info' while I was compiling glew-1.7.0. What was I missing in building Mesa-8.0.2? % nm -aD --defined /usr/lib/libxcb-glx.so.0 | grep client_info$ 47756d10 T xcb_glx_client_info $ nm -aD --defined /usr/lib/libxcb-glx.so.0 | grep client_info$ ddf0 T xcb_glx_client_info $ ldd libGL.so linux-gate.so.1 = (0x003d9000) libX11.so.6 = /usr/lib/libX11.so.6 (0x00588000) libXext.so.6 = /usr/lib/libXext.so.6 (0x0016c000) libXxf86vm.so.1 = /usr/lib/libXxf86vm.so.1 (0x0097c000) libXdamage.so.1 = /usr/lib/libXdamage.so.1 (0x009ed000) libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0x003a8000) libpthread.so.0 = /lib/libpthread.so.0 (0x006ea000) libdl.so.2 = /lib/libdl.so.2 (0x00dad000) libdrm.so.2 = /usr/local/mesa/lib/libdrm.so.2 (0x0023e000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x00248000) libm.so.6 = /lib/libm.so.6 (0x00aa4000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x008f5000) libc.so.6 = /lib/libc.so.6 (0x003da000) libxcb.so.1 = /usr/lib/libxcb.so.1 (0x0011) /lib/ld-linux.so.2 (0x0085f000) librt.so.1 = /lib/librt.so.1 (0x0012e000) libXau.so.6 = /usr/lib/libXau.so.6 (0x00137000) Note that neither one of the above libraries is mentioned in your ldd output, which means libGL was linked incorrectly. What method did you use to build Mesa? The default of the configuration was used. How should I change the default configure to link libX11-xcb and libxcb-glx properly? Thank you. --juper ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Mesa-8.0.2 libGL.so: undefined reference to `XGetXCBConnection'
Hi, I've just built Mesa-8.0.2 in a Linux box. Then there were errors of libGL.so: undefined reference to `XGetXCBConnection' and libGL.so: undefined reference to `xcb_glx_client_info' while I was compiling glew-1.7.0. What was I missing in building Mesa-8.0.2? $ ldd libGL.so linux-gate.so.1 = (0x003d9000) libX11.so.6 = /usr/lib/libX11.so.6 (0x00588000) libXext.so.6 = /usr/lib/libXext.so.6 (0x0016c000) libXxf86vm.so.1 = /usr/lib/libXxf86vm.so.1 (0x0097c000) libXdamage.so.1 = /usr/lib/libXdamage.so.1 (0x009ed000) libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0x003a8000) libpthread.so.0 = /lib/libpthread.so.0 (0x006ea000) libdl.so.2 = /lib/libdl.so.2 (0x00dad000) libdrm.so.2 = /usr/local/mesa/lib/libdrm.so.2 (0x0023e000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x00248000) libm.so.6 = /lib/libm.so.6 (0x00aa4000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x008f5000) libc.so.6 = /lib/libc.so.6 (0x003da000) libxcb.so.1 = /usr/lib/libxcb.so.1 (0x0011) /lib/ld-linux.so.2 (0x0085f000) librt.so.1 = /lib/librt.so.1 (0x0012e000) libXau.so.6 = /usr/lib/libXau.so.6 (0x00137000) Thank you. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
