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
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
On 03/25/2013 04:59 AM, jupiter wrote:
Hi Brian,
On 3/22/13, Brian Paulbri...@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
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
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
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
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
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
On 03/15/2013 05:33 PM, jupiter wrote:
Hi Brian,
On 3/15/13, Brian Paulbri...@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
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
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
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
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
On 03/14/2013 04:37 AM, jupiter wrote:
Hi Brian,
On 3/14/13, Brian Paulbri...@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
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
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
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
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
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.
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
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
On 03/07/2013 04:55 PM, jupiter 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
On 09.03.2013 01:06, Brian Paul 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?
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
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
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 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
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
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
28 matches
Mail list logo