Mesa built from commit 3f2c77659ca552c43f544228f3a5a5fe6365513a fails giving me a non working software renderer which leaves artifacts all over the background. Reverting to 827ba44f6ee83ab21c6a2b09323f6f1df4a7d4c8 works and glxinfo reports a render string of: Mesa DRI R600 (RS780 9614) 20090101 TCL DRI2. Rebuiling libdrm from git before building mesa does not change anything. I am on gentoo, amd64 with xorg 1.7.1, xf86-video-ati, libdrm & mesa from git. Kernel is 2.6.31.6 + Airlies drm-next tree as of Nov 6th. Hope this helps
Sounds like you are building against an old version of libdrm_radeon. To update build libdrm configured with --enable-radeon-experimental-api
(In reply to comment #1) > Sounds like you are building against an old version of libdrm_radeon. To > update build libdrm configured with --enable-radeon-experimental-api To avoid this problem current libdrm should be tagged as 2.4.16 and mesa should require libdrm_radeon >= 2.4.16.
This turns out not to be the case. As stated in the initial report libdrm is from git. My log shows the correct api enabled: >>> Emerging (1 of 1) x11-libs/libdrm-9999 from x11 * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... * GIT update --> * repository: git://anongit.freedesktop.org/git/mesa/drm Already up-to-date. * at the commit: b4312b639d56a6cad78953af0fd4f863182007e3 * branch: master * storage directory: "/usr/portage/distfiles/git-src/libdrm" Switched to a new branch 'branch-master' >>> Unpacked to /var/tmp/portage/x11-libs/libdrm-9999/work/libdrm-9999 * Running eautoreconf in '/var/tmp/portage/x11-libs/libdrm-9999/work/libdrm-9999' ... * Running aclocal ... [ ok ] * Running libtoolize --copy --force --install --automake ... [ ok ] * Running aclocal ... [ ok ] * Running autoconf ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy --foreign ... [ ok ] * Running elibtoolize in: libdrm-9999 * Applying portage-2.2.patch ... * Applying sed-1.5.6.patch ... * Applying as-needed-2.2.6.patch ... >>> Source unpacked in /var/tmp/portage/x11-libs/libdrm-9999/work >>> Compiling source in /var/tmp/portage/x11-libs/libdrm-9999/work/libdrm-9999 ... * econf: updating libdrm-9999/config.sub with /usr/share/gnuconfig/config.sub * econf: updating libdrm-9999/config.guess with /usr/share/gnuconfig/config.guess ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --prefix=/usr --datadir=/usr/share --enable-udev --enable-nouveau-experimental-api --enable-radeon-experimental-api
Could you try running: LIBGL_DEBUG=verbose glxgears
same thing here ... ~ $ LIBGL_DEBUG=verbose glxgears libGL: OpenDriver: trying /usr/lib64/dri/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib64/dri/r600_dri.so libGL error: dlopen /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: undefined symbol: radeon_ptr_2byte_8x2) libGL error: unable to load driver: r600_dri.so libGL error: driver pointer missing libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so 1273 frames in 5.0 seconds = 254.489 FPS 1235 frames in 5.0 seconds = 246.831 FPS
(In reply to comment #2) > To avoid this problem current libdrm should be tagged as 2.4.16 and mesa should > require libdrm_radeon >= 2.4.16. > That will be done once KMS is officially released upstream (makes it out of staging in the kernel). As it is now, the API may still change as evidenced by this commit. If you build a non-kms enabled mesa, you won't hit this issue.
(In reply to comment #5) > same thing here ... > > ~ $ LIBGL_DEBUG=verbose glxgears > libGL: OpenDriver: trying /usr/lib64/dri/tls/r600_dri.so > libGL: OpenDriver: trying /usr/lib64/dri/r600_dri.so > libGL error: dlopen /usr/lib64/dri/r600_dri.so failed > (/usr/lib64/dri/r600_dri.so: undefined symbol: radeon_ptr_2byte_8x2) > libGL error: unable to load driver: r600_dri.so > libGL error: driver pointer missing > libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so > libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so > 1273 frames in 5.0 seconds = 254.489 FPS > 1235 frames in 5.0 seconds = 246.831 FPS > Looks like a merge error. This was fixed in master a few days ago.
hmm.. thats strange, a new clone fixed the problems ... didn't get any changes with pull.
As discussed on irc while todays git fixed the dri problem, the corruptions persisted. As requested here is the commit the bisect found along with the log: grover mesa # git bisect good 286bf89e5a1fc931dbf523ded861b809859485e2 is the first bad commit commit 286bf89e5a1fc931dbf523ded861b809859485e2 Author: Maciej Cencora <m.cencora@gmail.com> Date: Wed Nov 11 13:06:19 2009 +0100 radeon/r300: no need to flush the cmdbuf when changing scissors state in KMM mode :040000 040000 432ee58dfddc9afa74201382f887f8557359f75d 43d9b8f07d6a9225614ac2882aff4a266056cf46 M src grover mesa # git bisect log # bad: [015e7e7724a64d3d9e02e57f6a8eb88a6441f596] r300g: emit R300_TEX_ENABLE to indicate there are no textures bound # good: [827ba44f6ee83ab21c6a2b09323f6f1df4a7d4c8] intel: Remove non-GEM support. git bisect start '015e7e7724a64d3d9e02e57f6a8eb88a6441f596' '827ba44f6ee83ab21c6a2b09323f6f1df4a7d4c8' # bad: [012d0193cc9ad6fdc9829db0a6884a5a590dd4c5] st/xorg: Don't complain about convolution filter being 'unknown'. git bisect bad 012d0193cc9ad6fdc9829db0a6884a5a590dd4c5 # skip: [afe84fa698eae3e035e967589f0a8d55f6a83698] r200: align for mipmap tree changes git bisect skip afe84fa698eae3e035e967589f0a8d55f6a83698 # bad: [ea114345a6f19331628910745650cb64750b2bda] st/xorg: Don't initialize non-existing fields. git bisect bad ea114345a6f19331628910745650cb64750b2bda # skip: [93eb2ab8c395f81e40fa298d78805bb2c777f891] radeon: align for mipmap tree changes git bisect skip 93eb2ab8c395f81e40fa298d78805bb2c777f891 # bad: [6e5d473cc16ca2d001df213fc1d907f2943a95bb] r300: fix regression introduced in 1d5a06a1f7812c055db1d724e40d21a0e3686dd1 git bisect bad 6e5d473cc16ca2d001df213fc1d907f2943a95bb # good: [084f43c1502db1988ca53494ea590cf1351180ec] radeon: add radeon_bo_is_referenced_by_cs function git bisect good 084f43c1502db1988ca53494ea590cf1351180ec # bad: [286bf89e5a1fc931dbf523ded861b809859485e2] radeon/r300: no need to flush the cmdbuf when changing scissors state in KMM mode git bisect bad 286bf89e5a1fc931dbf523ded861b809859485e2 # good: [f6d0993212fac0eb67827716be1ab4a292c8b4e5] radeon: fix glBufferSubData git bisect good f6d0993212fac0eb67827716be1ab4a292c8b4e5
Just to confirm, reverting 286bf89e5a1fc931dbf523ded861b809859485e2 fixes the corruption here.
added cc
*** Bug 25251 has been marked as a duplicate of this bug. ***
Please always include the one-line summary along with Git commit IDs, so humans can make sense of them.
Can you retry with current mesa_7_7_branch ? This could be a similar issue of bug #25230.
This happens with both master and mesa_7_7_branch. It does not happen with mesa_7_6_branch (unsurprisingly, since that branch does not contain 286bf89e5a1fc931dbf523ded861b809859485e2) A Phoronix forum thread already exists, http://www.phoronix.com/forums/showthread.php?t=20532
(In reply to comment #14) > Can you retry with current mesa_7_7_branch ? > This could be a similar issue of bug #25230. Problem still exists on mesa_7_7_branch HEAD, latest commit 270d36da146b899d39e08f830fe34b63833a3731.
The corruption still exists at 09325b9ff456ae475069bac5a04cf10a32235e43 on master. It also is present in 7.7-rc1. Reverting 286bf89e5a1fc931dbf523ded861b809859485e2 still fixes it on head. Its probably a good idea to fix this before 7.7-rc2 is released...
(In reply to comment #17) > > Its probably a good idea to fix this before 7.7-rc2 is released... > Agreed. this is a 7.7 release showstopper. Suggest reverting now, unless Maciej is close to a fix.
Reverted via e84dddde9b6eb7727760814ae211c95218bb28a3.
Reverted: http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_7_branch&id=e84dddde9b6eb7727760814ae211c95218bb28a3
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.