Hi Brian,
On 3/26/13, Brian Paul 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_t
On 03/25/2013 04:59 AM, jupiter wrote:
Hi Brian,
On 3/22/13, Brian Paul wrote:
On 03/21/2013 03:51 AM, jupiter wrote:
Hi Brian,
On 3/21/13, Brian Paul wrote:
On 03/20/2013 04:07 AM, jupiter wrote:
Hi Brian,
On 3/19/13, Brian Paulwrote:
It is fair to say, if running llvm driver in m
Hi Brian,
On 3/22/13, Brian Paul wrote:
> On 03/21/2013 03:51 AM, jupiter wrote:
>> Hi Brian,
>>
>> On 3/21/13, Brian Paul wrote:
>>> On 03/20/2013 04:07 AM, jupiter wrote:
Hi Brian,
On 3/19/13, Brian Paul wrote:
>> It is fair to say, if running llvm driver in my local machi
On 03/21/2013 03:51 AM, jupiter wrote:
Hi Brian,
On 3/21/13, Brian Paul wrote:
On 03/20/2013 04:07 AM, jupiter wrote:
Hi Brian,
On 3/19/13, Brian Paul 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 th
Hi Brian,
On 3/21/13, Brian Paul wrote:
> On 03/20/2013 04:07 AM, jupiter wrote:
>> Hi Brian,
>>
>> On 3/19/13, Brian Paul 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.
On 03/20/2013 04:07 AM, jupiter wrote:
Hi Brian,
On 3/19/13, Brian Paul 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
Hi Brian,
On 3/19/13, Brian Paul 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
Hi Brian,
On 3/19/13, Brian Paul 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
On 03/15/2013 05:33 PM, jupiter wrote:
Hi Brian,
On 3/15/13, Brian Paul wrote:
On 03/15/2013 05:39 AM, jupiter wrote:
Thanks Brian and Matt.
On 3/15/13, Matt Turner wrote:
On Thu, Mar 14, 2013 at 6:29 AM, Brian Paul wrote:
Hmm, I guess autoconf still has some unneeded dependencies on D
Hi Brian,
On 3/15/13, Brian Paul wrote:
> On 03/15/2013 05:39 AM, jupiter wrote:
>> Thanks Brian and Matt.
>>
>> On 3/15/13, Matt Turner wrote:
>>> On Thu, Mar 14, 2013 at 6:29 AM, Brian Paul wrote:
Hmm, I guess autoconf still has some unneeded dependencies on DRI when
it's
not n
On 03/15/2013 05:39 AM, jupiter wrote:
Thanks Brian and Matt.
On 3/15/13, Matt Turner wrote:
On Thu, Mar 14, 2013 at 6:29 AM, Brian Paul 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
Thanks Brian and Matt.
On 3/15/13, Matt Turner wrote:
> On Thu, Mar 14, 2013 at 6:29 AM, Brian Paul 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 selecte
On Thu, Mar 14, 2013 at 6:29 AM, Brian Paul 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= s
On 03/14/2013 04:37 AM, jupiter wrote:
Hi Brian,
On 3/14/13, Brian Paul 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 Paul wrote:
Well, the Xlib/swrast driver does everything in software, unlike a DRI
driver which
Hi Brian,
On 3/14/13, Brian Paul 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 Paul wrote:
>>> Well, the Xlib/swrast driver does everything in software, unlike a DRI
>>> driver which does most things with
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 Paul 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
Hi Brian,
Sorry for not being clear, let me clarify it.
On 3/13/13, Brian Paul 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
acc
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 lib/
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 yo
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 an
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
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?
'mak
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?
Maybe post your config.log file.
-Brian
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?
$ ls -l
total 42620
-rwxr-xr-x 1 root root 1196 Mar 8 10:47 libEGL.la
lrwxrwxrwx 1 root root 15 Mar 8 10:49 libEGL.so -> libEGL.so.1.0.0
lrwxrwx
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 configurati
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 ot
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
dis
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-gl
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
30 matches
Mail list logo
