[blfs-dev] New packages today from upstream

Armin K. krejzi at email.com
Fri Aug 2 06:48:31 PDT 2013


On 08/02/2013 03:42 PM, Ken Moffat wrote:
> On Fri, Aug 02, 2013 at 03:00:37PM +0200, Armin K. wrote:
>>>
>>> I guess it's r600-llvm-compiler which is broken, but we don't enable
>>> that by default. Compiling Mesa now.
>>>
>>
>> Okay, hacked it to build, r600 works fine (no llvm backend enabled) but
>> llvmpipe (llvm accelerated software rasterizer) performance is more than
>> terrible. Lets hope no one uses it on a daily basis.
>>
>> http://i.imgur.com/m2Gc6lA.png
>>
>> It's a discrete card (hybrid graphics laptop) so that's why performance
>> is so terrible - same with 9.2 git from several days ago.
> 
>  BTW, there is a testsuite in 9.2, I added --enable-gallium-tests.
> I got (at least) one error - it stops make check at that point.
> Haven't had time to report it yet, still trying to understand a
> bigger annoyance (xscreensaver can't load the r600 driver on GL
> savers such as GLHanoi).  Works fine if I alter the perms on
> /dev/dri/card0 to m660 - yes, I'm in the video group, glxinfo/gears
> run ok (your patch for xdemos is fine in 9.2), and xscreensaver runs
> as user ken.  Guess I'll need to ask elsewhere about that one, it's
> taken me days to get this far in understanding the problem and I've
> no idea what part of this is apparently becoming some other user.
> 

It appears your udev fails to do the work. cardx node permissions should
be 660 and owned by root:video by default (set by udev)

$ ls -l /dev/dri/card*
crw-rw----+ 1 root video 226, 0 Aug  2 14:41 /dev/dri/card0
crw-rw----+ 1 root video 226, 1 Aug  2 14:41 /dev/dri/card1

>  In 9.1.* I had a lot of segfaults in the r600 GL savers, never got
> as far as discovering the perms error (didn't try passing
> LIBGL_DEBUG=verbose when I started xscreensaver :)  Anyway, getting
> back on topic -
> 
>  For 9.2, with my configure options, I got a message that radeonsi
> and r600g require libelf.  Found that, straight CMMI but no obvious
> way to prevent it installing static lib (and uses instroot instead
> of DESTDIR - how many other variations are there ;-).  I see that
> arch uses elfutils from fedora-hosted, but that looks equally messy.
> Do you need either of these, or is it just my "try everything"
> config of Mesa-9.2 ?
> 
> ĸen
> 

I just added elfutils few minutes ago. Yes, it is *necesary* for both
r600 and radeonsi, at least for my setup (which is more or less
identical to one in LFS).

$ ldd /usr/lib{,32}/dri/{r600,radeonsi}_dri.so
/usr/lib/dri/r600_dri.so:
	linux-vdso.so.1 (0x00007fff2b1ff000)
	libz.so.1 => /lib/libz.so.1 (0x00007ffa903bd000)
	libffi.so.6 => /usr/lib/libffi.so.6 (0x00007ffa901b4000)
	libelf.so.1 => /usr/lib/libelf.so.1 (0x00007ffa8ff9e000)
	libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007ffa8fd75000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007ffa8fb59000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007ffa8f954000)
	libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007ffa8f748000)
	libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0x00007ffa8f53c000)
	libLLVM-3.3.so => /usr/lib/libLLVM-3.3.so (0x00007ffa8dc61000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007ffa8d95e000)
	libm.so.6 => /lib/libm.so.6 (0x00007ffa8d660000)
	libc.so.6 => /lib/libc.so.6 (0x00007ffa8d2b2000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007ffa8d09c000)
	/lib/ld-linux-x86-64.so.2 (0x00007ffa91034000)
/usr/lib/dri/radeonsi_dri.so:
	linux-vdso.so.1 (0x00007fff30536000)
	libz.so.1 => /lib/libz.so.1 (0x00007f7813350000)
	libffi.so.6 => /usr/lib/libffi.so.6 (0x00007f7813147000)
	libelf.so.1 => /usr/lib/libelf.so.1 (0x00007f7812f31000)
	libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007f7812d25000)
	libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f7812afc000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f78128df000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f78126db000)
	libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0x00007f78124cf000)
	libLLVM-3.3.so => /usr/lib/libLLVM-3.3.so (0x00007f7810bf4000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f78108f1000)
	libm.so.6 => /lib/libm.so.6 (0x00007f78105f3000)
	libc.so.6 => /lib/libc.so.6 (0x00007f7810245000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f781002f000)
	/lib/ld-linux-x86-64.so.2 (0x00007f7813ef1000)
/usr/lib32/dri/r600_dri.so:
	linux-gate.so.1 (0xffffe000)
	libz.so.1 => /usr/lib32/libz.so.1 (0xf6ec8000)
	libffi.so.6 => /usr/lib32/libffi.so.6 (0xf6ec1000)
	libexpat.so.1 => /usr/lib32/libexpat.so.1 (0xf6e99000)
	libpthread.so.0 => /lib32/libpthread.so.0 (0xf6e7e000)
	libdl.so.2 => /lib32/libdl.so.2 (0xf6e78000)
	libdrm.so.2 => /usr/lib32/libdrm.so.2 (0xf6e6c000)
	libdrm_radeon.so.1 => /usr/lib32/libdrm_radeon.so.1 (0xf6e5f000)
	libLLVM-3.3.so => /usr/lib32/libLLVM-3.3.so (0xf571e000)
	libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf5637000)
	libm.so.6 => /lib32/libm.so.6 (0xf55f3000)
	libc.so.6 => /lib32/libc.so.6 (0xf5448000)
	libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf542e000)
	/lib32/ld-linux.so.2 (0xf771f000)
/usr/lib32/dri/radeonsi_dri.so:
	linux-gate.so.1 (0xffffe000)
	libz.so.1 => /usr/lib32/libz.so.1 (0xf701c000)
	libffi.so.6 => /usr/lib32/libffi.so.6 (0xf7015000)
	libelf.so.1 => /usr/lib32/libelf.so.1 (0xf6ffe000)
	libdrm.so.2 => /usr/lib32/libdrm.so.2 (0xf6ff2000)
	libexpat.so.1 => /usr/lib32/libexpat.so.1 (0xf6fc9000)
	libpthread.so.0 => /lib32/libpthread.so.0 (0xf6fae000)
	libdl.so.2 => /lib32/libdl.so.2 (0xf6fa9000)
	libdrm_radeon.so.1 => /usr/lib32/libdrm_radeon.so.1 (0xf6f9c000)
	libLLVM-3.3.so => /usr/lib32/libLLVM-3.3.so (0xf585b000)
	libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf5773000)
	libm.so.6 => /lib32/libm.so.6 (0xf5730000)
	libc.so.6 => /lib32/libc.so.6 (0xf5585000)
	libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf556b000)
	/lib32/ld-linux.so.2 (0xf77c5000)




More information about the blfs-dev mailing list