Upon starting x loading r600_dri.so fails first bad commit : http://cgit.freedesktop.org/mesa/mesa/commit/?id=f70c3853513637fa6ed38e75f73d472a9fa61213 ------------------------------------------------------------- ./autogen.sh --prefix=/usr \ --sysconfdir=/etc \ --with-dri-driverdir=/usr/lib/xorg/modules/dri \ --with-gallium-drivers=r300,r600,radeonsi,swrast \ --with-dri-drivers=swrast \ --enable-gallium-llvm \ --enable-egl \ --enable-gallium-egl \ --with-egl-platforms=x11,drm,wayland \ --enable-shared-glapi \ --enable-gbm \ --enable-glx-tls \ --enable-dri \ --enable-glx \ --enable-osmesa \ --enable-gles1 \ --enable-gles2 \ --enable-texture-float \ --enable-xa \ --enable-vdpau \ --enable-gallium-gbm \ --enable-gallium-g3dvl \ --enable-xvmc \ --enable-xorg \ --enable-r600-llvm-compiler \ --with-llvm-shared-libs --------------------------------------------------- I've chosen blocker as severity, as this commit is a candidate for the 9.1 branch
Can you be more specific on how it fails?
X can't initialize the driver and falls back to software rastering. excerpt from Xorg.0.log : [ 12609.742] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libllvmradeon9.2.0.so: undefined symbol: lp_build_tgsi_intrinsic) [ 12609.742] (EE) AIGLX: reverting to software rendering [ 12609.742] (II) AIGLX: Screen 0 is not DRI capable [ 12609.746] (II) AIGLX: Loaded and initialized swrast additional info : OS : Archlinux x86_64 kernel 3.8.3 , https://www.archlinux.org/packages/testing/x86_64/linux/ xf86-video-ati 7.1.0, https://www.archlinux.org/packages/testing/x86_64/xf86-video-ati/ I'll attach the build output and complete Xorg.0.log
Created attachment 76641 [details] build output
Created attachment 76642 [details] complete Xorg.0.log
Created attachment 76652 [details] [review] Possible patch Does this patch help?
Tom, could you look at this bug?
yes, the patch in comment #5 solves the problem. Looking at the 'bad' commit, it seems the changes in src/gallium/auxiliary/Makefile.am required a change in the src/gallium/drivers/radeon/Makefile.am ? If so, i wonder if other drivers then radeon are affected also. The patch looks more as a workaround then as a real solution.
(In reply to comment #5) > Possible patch This seems less than ideal, as it makes libllvmradeon duplicate lots of stuff from the driver *.so, and it grows from ~500K to ~10M for me.
That appears to be correct, in a git version build on march 11 libllvmradeon9.2.0.so is just 39 Kib . Build with the patch it's size increases to 1.8 Mib !
(In reply to comment #8) > (In reply to comment #5) > > Possible patch > > This seems less than ideal, as it makes libllvmradeon duplicate lots of > stuff from the driver *.so, and it grows from ~500K to ~10M for me. Hmm we definitely need a shared libgallium. That would reduce the size of all gallium drivers. Or we could remove/revert the visibility flags from src/gallium/auxiliary/Makefile.am
The fix is correct, despite the size increase.
Reverting the gallium fix would reopen bug #59238
Ubuntu is providing a shared libgallium, the patches are here: http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=tree;f=debian/patches;hb=refs/heads/ubuntu%2B1
Trying to summarize I've looked a bit more at bug #59238, and if i understand correctly the problem with building xa tracker was that symbols were exported that are not supposed to be visible outside of the library itself ? By adding the VISIBILITY_CFLAGS and VISIBILITY_CXXFLAGS changes in the f70c385 commit, the troublesome symbols were removed. A consequence however was that symbols needed for r600_dri.so to call libllvmradeon9.2.0.so were no longer present. Including $(top_builddir)/src/gallium/auxiliary/libgallium.la in src/gallium/drivers/radeon/Makefile.am makes sure all needed symbols are present, but has a size increase of libllvmradeon9.2.0 as downside. To counter the size increase, switching to a shared libgallium is proposed.
Can you please fix this somehow for now? This is preventing radeonsi from working at all.
(In reply to comment #15) > Can you please fix this somehow for now? This is preventing radeonsi from > working at all. I've sent the proposed patch from comment #5 to the list: http://lists.freedesktop.org/archives/mesa-dev/2013-March/036423.html
(In reply to comment #12) > Reverting the gallium fix would reopen bug #59238 FWIW, that seems less of an issue to me than this bug or the side effects of the attached patch.
The size increase only happens if radeonsi is built too, and can be countered with the shared libgallium patch. The original bug described here is fixed with these 2 commits: 36320bfa54b758b34 - radeon/llvm: Link against libgallium.la to fix an undefined symbol 7c3d8301afed46cf9 - radeon/llvm: Do not link against libgallium when building statically.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.