Created attachment 69083 [details] Distorted graphics On my dell vostro laptop I get distorted graphics. I use Gnome3 shell. See attached screen shot. The kernel used is 3.6.3-1-ARCH. I found the problem is apparent with the versions 9.0-1 of ati-dri and libgl and is not seen when I downgrade to the versions: ati-dri-8.0.4-3-x86_64.pkg.tar.xz libgl-8.0.4-3-x86_64.pkg.tar.xz
Can you checkout mesa from git an bisect? Also please attach your xorg log and dmesg output.
Created attachment 69132 [details] dmesg
Created attachment 69133 [details] Xorg.0.log
The dmesg and xorg log files are done with the top of the 9.0 branch 5fe5aa8e55a8db0b80f6ff9838bad47ce0406fd0
And the bug still exists when using the top of the master branch: b78b62497f1e5cc64eb924c64e4685fe5d814fd7 I'm not so sure what commits I should start the bisecting with since 8.0 and 9.0 are split. It is not a linear history.
You can just checkout a commit on master around the time 8.0 was branched.
I have not found the bug by bisecting, but I can't go on because the commits do not compile anymore. So far my results are: e656c4a07420fbb34cf00f9b827b1d2f4c45e0f6 bad 67e9ae856355be532455c1cf1211d59b3a4c5992 bad bee2edbf3d2da2c2351c70e56da0dca205caa8ea bad 10e552d056dd080c4e763a31df517c2d7684a9cf bad 72f7632c6bbbfc062ac7d90290e99f71272f6059 bad 94b634eca0e2bd32d4b5bd92d06d510eae8a5625 broken, does not compile used instead of the broken commit, it compiles but is bad 97b4b97b2f9b0e4532c8ba9cedfff9f013a76fc2 bad here I stop
*** Bug 56464 has been marked as a duplicate of this bug. ***
*** Bug 56666 has been marked as a duplicate of this bug. ***
I could still do some bisecting if anyone could help me building the packages ati-dri and libg. I'm using a modified PKGBUILD. I guess I don't need everything build by that script. In order to get around some compilation errors that occurs in parts I don't need anyway it would probably help to tailor the building exactly for what I need. But I don't know what is needed. Maybe someone can help on this. I attach PKGBUILD.
Created attachment 69497 [details] script to build libraries and drivers
What are the compile errors?
Created attachment 69640 [details] compilation errors These are the compile errors I get with the above mentioned commit. The compile errors are fixed in the commit also mentioned above. When I choose the start end endpoints for the bisecting I looked at the date of the commit. And the commit I related to the 8.0 tag by the date does not compile either. So this was not a good starting point in the first place. I guess it would be better to bisect between the mesa-8.0.4 and mesa-9.0 tags. If I try this git asks me to check a merge base first. This merge base dates back to January and it seams to have a very different configure/build structure.
(In reply to comment #13) > These are the compile errors I get with the above mentioned commit. > The compile errors are fixed in the commit also mentioned above. One strategy for such cases is to look at the commit fixing the compile error and see if (part of) it can be applied on top of other commits to be tested for the bisect. > And the commit I related to the 8.0 tag by the date > does not compile either. So this was not a good starting point > in the first place. Indeed, you should never declare a commit good or bad if it doesn't even compile. :) > I guess it would be better to bisect between the mesa-8.0.4 and mesa-9.0 > tags. > If I try this git asks me to check a merge base first. Yes, that's how it deals with non-linear history (so you don't have to worry about that yourself). > This merge base dates back to January and it seams to have > a very different configure/build structure. Maybe it would be easier to just do manual builds instead of using PKGBUILD for the bisect? You can point to the directory containing the manually built r600_dri.so with the environment variable LIBGL_DRIVERS_PATH. You may also want to set LIBGL_DEBUG=verbose to verify it's picking up the expected r600_dri.so. Also, especially for older commits, you may need to run make clean or even autogen.sh between bisection steps to prevent inconsistent builds.
I tried to compile c1f4867c89adb1a6b19d66ec8ad146115909f0a7 the commit taged with mesa-8.0.4 and I get the following compilation error: g++ -c -I. -I../../../src/gallium/include -I../../../src/gallium/auxiliary -I../../../src/gallium/drivers -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -fno-strict-aliasing -fno-builtin-memcmp -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fPIC -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XCB_DRI2 -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0301 -fvisibility=hidden -I/usr/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS gallivm/lp_bld_debug.cpp -o gallivm/lp_bld_debug.o gallivm/lp_bld_debug.cpp: In function ‘void lp_disassemble(const void*)’: gallivm/lp_bld_debug.cpp:240:66: error: no matching function for call to ‘llvm::Target::createMCInstPrinter(unsigned int&, const llvm::MCAsmInfo&, const llvm::MCSubtargetInfo&) const’ gallivm/lp_bld_debug.cpp:240:66: note: candidate is: In file included from gallivm/lp_bld_debug.cpp:37:0: /usr/include/llvm/Support/TargetRegistry.h:395:20: note: llvm::MCInstPrinter* llvm::Target::createMCInstPrinter(unsigned int, const llvm::MCAsmInfo&, const llvm::MCInstrInfo&, const llvm::MCRegisterInfo&, const llvm::MCSubtargetInfo&) const /usr/include/llvm/Support/TargetRegistry.h:395:20: note: candidate expects 5 arguments, 3 provided make[3]: *** [gallivm/lp_bld_debug.o] Error 1 make[3]: Leaving directory `/home/michael/src/Mesa/mesa/src/gallium/auxiliary' make[2]: *** [default] Error 1 make[2]: Leaving directory `/home/michael/src/Mesa/mesa/src/gallium' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/michael/src/Mesa/mesa/src' make: *** [default] Error 1
I compiled the commit 6671d0dad300e591ac7c0e5110c6778373d0149a which I picked to start bisecting. (I picked it because the date is related to the date of the 8.0 branch as mentioned above) It shows the same problem. In order to get it compiled I had to do the foloowing change: --- a/src/gallium/state_trackers/egl/common/egl_g3d_api.c +++ b/src/gallium/state_trackers/egl/common/egl_g3d_api.c @@ -53,7 +53,7 @@ egl_g3d_choose_st(_EGLDriver *drv, _EGLContext *ctx, switch (ctx->ClientAPI) { case EGL_OPENGL_ES_API: - switch (ctx->ClientVersion) { + switch (ctx->ClientMajorVersion) { case 1: api = ST_API_OPENGL; *profile = ST_PROFILE_OPENGL_ES1; @@ -64,7 +64,7 @@ egl_g3d_choose_st(_EGLDriver *drv, _EGLContext *ctx, break; default: _eglLog(_EGL_WARNING, "unknown client version %d", - ctx->ClientVersion); + ctx->ClientMajorVersion); break; And I changed my build script in order not to build vdpau and radeonsi and some other things I beleive are not related to the driver r600 I beleive I need.
(In reply to comment #14) > (In reply to comment #13) > Maybe it would be easier to just do manual builds instead of using PKGBUILD > for the bisect? You can point to the directory containing the manually built > r600_dri.so with the environment variable LIBGL_DRIVERS_PATH. You may also > want to set LIBGL_DEBUG=verbose to verify it's picking up the expected > r600_dri.so. At which point would I need to have the environment setup in order to pick the driver? Can I just stop gdm set the environment and start gdm with systemctl? > > Also, especially for older commits, you may need to run make clean or even > autogen.sh between bisection steps to prevent inconsistent builds. There are a lot of options. Which are relevant? COMMONOPTS="--prefix=/usr \ --sysconfdir=/etc \ --with-dri-driverdir=/usr/lib/xorg/modules/dri \ --with-gallium-drivers=r300,r600,radeonsi,nouveau,svga,swrast \ --with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast \ --enable-gallium-llvm \ --enable-egl \ --enable-gallium-egl \ --with-egl-platforms=x11,drm \ --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 "
(In reply to comment #17) > Can I just stop gdm set the environment and start gdm with systemctl? I don't think so. It mainly needs to be in gnome-shell's environment, but I'm not sure offhand how best to achieve that with your setup. > --with-gallium-drivers=r300,r600,radeonsi,nouveau,svga,swrast \ You only need r600 and maybe swrast here. > --with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast \ You can set this to an empty string. > --enable-egl \ > --enable-gallium-egl \ > --with-egl-platforms=x11,drm \ Shouldn't need these. > --enable-gbm \ Shouldn't need this. > --enable-osmesa \ Don't need this. > --enable-gles1 \ > --enable-gles2 \ Shouldn't need these. > --enable-xa \ > --enable-vdpau " Don't need these.
I'm stuck with: g++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fPIC -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XCB_DRI2 -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0301 -fvisibility=hidden -o r600_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o r600_dri.so.tmp -L../../../../lib -Wl,-R/usr/lib/xorg/modules/dri -ldricore -lglsl -ldrm -lexpat -lm -lpthread -ldl -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/lib/llvm -lpthread -lffi -ldl -lm ; r600_dri.so.tmp: undefined reference to `st_gl_api_create' I have 15 commits left to test. I did skip commits in order to get rid of the missing reference. I already skipped 5 commits and the reference still is missing. I had to apply some other patches already. Anyway I'm not even convinced my test is a good test. Because since a while I only get the r600_dri.so built. And I only exchange this object. I wonder if really nobody of the developers sees the problem at all? Even if I would succeed in finding the bad commit how would you fix it if you can not reproduce the problem?
(In reply to comment #19) > Even if I would succeed in finding the bad commit how would you fix > it if you can not reproduce the problem? It will help narrow down what's causing the problem and give us a place to start looking. It may be a very simple fix. Without narrowing it down further, it's hard to even propose any fixes.
(In reply to comment #19) > I have 15 commits left to test. Which ones? > Anyway I'm not even convinced my test is a good test. Because since a while I > only get the r600_dri.so built. And I only exchange this object. FWIW, that's perfectly plausible as you're narrowing down the range of potential culprit commits. This object does contain the bulk of relevant code.
Created attachment 70326 [details] bisect log I think all the information can be derived by replaying bisect log information from the file I attached.
Created attachment 70327 [details] [review] patch I used for compilation This is git diff -p output showing the patches I applied to get some thing compiled.
(In reply to comment #22) > bisect log It does look like you're getting close to isolating a commit. Most likely it's one of the remaining r600g commits, but there's still too many of them to guess which one. (In reply to comment #23) > patch I used for compilation Some of this looks a little dubious, but I guess it should do for the bisection. For the latest compile problem, have you tried manually applying the two revert commits at the end of the remaining commits?
I have not tried that before. Now I cherry picked 0b616b2f5164621e3a63caeb15c6eb1d01bbc55a 4a162f6eba73a8cb2654cd99a2bd12bd468925a6 on top of 302862defa61b2cee1ae24159aca306f090ca854 The r600_dri.so did compile now. But now gnome starts in fallback mode with the new r600_dri.so. And in this mode I can not test the problem.
(In reply to comment #25) > But now gnome starts in fallback mode with the new r600_dri.so. Does LIBGL_DEBUG=verbose glxinfo | grep render give any hints as to what might be wrong with this r600_dri.so?
(In reply to comment #26) > (In reply to comment #25) > LIBGL_DEBUG=verbose glxinfo | grep render I don't have glxinfo
(In reply to comment #27) > (In reply to comment #26) > > (In reply to comment #25) > > LIBGL_DEBUG=verbose glxinfo | grep render > I don't have glxinfo Ah I found it on archlinux AUR in the package mesa-demo-git. I'm just building it.
(In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #26) > > > (In reply to comment #25) > > > LIBGL_DEBUG=verbose glxinfo | grep render > > I don't have glxinfo > > Ah I found it on archlinux AUR in the > package mesa-demo-git. I'm just > building it. Here is the result: libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/r600_dri.so libGL error: dlopen /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/libglsl.so: undefined symbol: hash_table_string_hash) libGL error: unable to load driver: r600_dri.so libGL error: driver pointer missing libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/swrast_dri.so
I found I made a mistake during bisecting. In order to get rid of the latest compile problem I upgraded libgl to the 9.0.1 version. Now gnome starts and does not show the problem. I finished bisecting and found no more bad commits. To cross check I tried the last bad commit 8c436b4ea670d4630767a742dac5aad14e18aef9. But I found it good this time. I downgraded libgl again to 8.0.4. Now gnome does not start but finds a problem it can not recover from. I don't know what I had the firost time I checked 8c436b4ea670d4630767a742dac5aad14e18aef9.
(In reply to comment #29) > libGL error: dlopen /usr/lib/xorg/modules/dri/r600_dri.so failed > (/usr/lib/libglsl.so: undefined symbol: hash_table_string_hash) Is /usr/lib/libglsl.so built from your Mesa tree? Generally check that r600_dri.so, libGL.so.1 and any binaries they link against are picked up from your Mesa tree for the bisection. (In reply to comment #30) > In order to get rid of the latest compile problem > I upgraded libgl to the 9.0.1 version. > Now gnome starts and does not show the problem. So that got rid of the undefined symbol above? Hmm. Sounds like it was/is not picking up all relevant binaries from your Mesa tree.
Created attachment 70453 [details] new bisect log I started bisecting from the second last bad commit. I could verify it's bad. The new bisect log output shows the current status. I'm now testing the r600_dri.so with both libgl libraries. I do not point to my built tree for loading the libraries or objects. What I do is replace the r600_dri.so in /usr/lib/xorg/modules/dri/r600_dri.so with the one I built. I now test it twice with libgl 8.0.4 and 9.0.1.
Created attachment 70454 [details] the patch I used lately This is a patch I need to apply in order to get at least r600_dri.so compiled. Could the bug be in there? I guess not.
I finished bisecting (again). The result looks like this: git bisect bad c0c979eebc076b95cc8d18a013ce2968fe6311ad is the first bad commit commit c0c979eebc076b95cc8d18a013ce2968fe6311ad Author: Jerome Glisse <jglisse@redhat.com> Date: Mon Jan 30 17:22:13 2012 -0500 r600g: add support for common surface allocator for tiling v13 Tiled surface have all kind of alignment constraint that needs to be met. Instead of having all this code duplicated btw ddx and mesa use common code in libdrm_radeon this also ensure that both ddx and mesa compute those alignment in the same way. v2 fix evergreen v3 fix compressed texture and workaround cube texture issue by disabling 2D array mode for cubemap (need to check if r7xx and newer are also affected by the issue) v4 fix texture array v5 fix evergreen and newer, split surface values computation from mipmap tree generation so that we can get them directly from the ddx v6 final fix to evergreen tile split value v7 fix mipmap offset to avoid to use random value, use color view depth view to address different layer as hardware is doing some magic rotation depending on the layer v8 fix COLOR_VIEW on r6xx for linear array mode, use COLOR_VIEW on evergreen, align bytes per pixel to a multiple of a dword v9 fix handling of stencil on evergreen, half fix for compressed texture v10 fix evergreen compressed texture proper support for stencil tile split. Fix stencil issue when array mode was clear by the kernel, always program stencil bo. On evergreen depth buffer bo need to be big enough to hold depth buffer + stencil buffer as even with stencil disabled things get written there. v11 rebase on top of mesa, fix pitch issue with 1d surface on evergreen, old ddx overestimate those. Fix linear case when pitch*height < 64. Fix r300g. v12 Fix linear case when pitch*height < 64 for old path, adapt to libdrm API change v13 add libdrm check Signed-off-by: Jerome Glisse <jglisse@redhat.com> :100644 100644 af1e914f35aebf24c4824e93804c9f9088be7333 b2b1ab8f41a131089b84325fef962f7d4d79bb8d M configure.ac :040000 040000 facdf8849a029e15e166ffcf17c2db2d57ee9530 fa9bf703af2882d35c8d7e83022c8b80d43ae390 M src
To confirm, does: Option "ColorTiling2D" "false" in the device section of your xorg.conf also fix the issues?
(In reply to comment #35) > To confirm, does: > Option "ColorTiling2D" "false" > in the device section of your xorg.conf also fix the issues? No it does not solve this bug but it solves bug #56986 for me.
For me "ColorTiling2D" "false" doesn't help too.
The distorted graphics problem disappears when setting the option Option "NoAccel" "on". (This may be obvious to the experts.) In this mode a new phenomenon appears: When moving th mouse to the Activities corner and the "summarizing display" is shown, the background consists of a corrupted image.
(In reply to comment #38) > The distorted graphics problem disappears when setting the option > Option "NoAccel" "on". > (This may be obvious to the experts.) > > In this mode a new phenomenon appears: When moving th mouse to the > Activities corner and the "summarizing display" is shown, the background > consists of a corrupted image. That option disables all hardware acceleration. All rendering is done in software.
Any update?
Created attachment 71284 [details] [review] Patch gpu pipe Does this kernel patch fix the issue ?
case CHIP_SUMO2: - rdev->config.evergreen.num_ses = 1; + rdev->config.evergreen.num_ses = 2; None of the APUs have multiple SEs.
(In reply to comment #42) > case CHIP_SUMO2: > - rdev->config.evergreen.num_ses = 1; > + rdev->config.evergreen.num_ses = 2; > > None of the APUs have multiple SEs. So it waste of time, to try that patch?
(In reply to comment #43) > (In reply to comment #42) > > case CHIP_SUMO2: > > - rdev->config.evergreen.num_ses = 1; > > + rdev->config.evergreen.num_ses = 2; > > > > None of the APUs have multiple SEs. > > So it waste of time, to try that patch? Please try it. Your card is not a SUMO2.
(In reply to comment #41) > Created attachment 71284 [details] [review] [review] > Patch gpu pipe > > Does this kernel patch fix the issue ? Yes it does solve the bug! And it seams to solve bug #56720 too. Excellent, well done, thank you Jerome.
*** Bug 56720 has been marked as a duplicate of this bug. ***
*** Bug 58115 has been marked as a duplicate of this bug. ***
(In reply to comment #41) > Created attachment 71284 [details] [review] [review] > Patch gpu pipe > > Does this kernel patch fix the issue ? Does this patch get into kernel 3.8?
(In reply to comment #48) > Does this patch get into kernel 3.8? Yes. It will be in 3.8 and the stable kernels.
*** Bug 58634 has been marked as a duplicate of this bug. ***
A patch referencing this bug report has been merged in Linux v3.8-rc1: commit bd25f0783dc3fb72e1e2779c2b99b2d34b67fa8a Author: Jerome Glisse <jglisse@redhat.com> Date: Tue Dec 11 11:56:52 2012 -0500 drm/radeon: fix amd afusion gpu setup aka sumo v2
Fix works for me.
Yesterday I installed 3.8rc1 and also can confirm - fix works for me too. Thanks! Michael, if you also doesn't have this problem anymore please close the ticket.
The patch works for me, as alread reported. I have not tried a kernel including the patch. But I still think this bug is fixed.
I'm running the latest mesa and kernels from git and I think I may have encountered this issue Everything works fine using i965, using prime with R600_LLVM=1 is also ok however when running with R600_LLVM=0 I got similar error messages about being out of memory This seemed to happen when I was testing out the highest settings of WoW - disappointingly the i965 had the highest fps
Created attachment 75082 [details] Dmesg output
I got lots of radeon: The kernel rejected CS, see dmesg for more information. from the wine process If this is a separate issue I'll look into it more tomorrow
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.