https://bugs.freedesktop.org/show_bug.cgi?id=56405
Priority: medium Bug ID: 56405 Assignee: dri-devel@lists.freedesktop.org Summary: Distorted graphics on Radeon HD 6620G Severity: critical Classification: Unclassified OS: Linux (All) Reporter: mdrslmr@t-online.de Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: Drivers/DRI/Radeon Product: Mesa
Created attachment 69083 --> https://bugs.freedesktop.org/attachment.cgi?id=69083&action=edit 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
https://bugs.freedesktop.org/show_bug.cgi?id=56405
mdrslmr@t-online.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #69083|text/plain |image/png mime type| |
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #1 from Alex Deucher agd5f@yahoo.com --- Can you checkout mesa from git an bisect? Also please attach your xorg log and dmesg output.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #2 from mdrslmr@t-online.de --- Created attachment 69132 --> https://bugs.freedesktop.org/attachment.cgi?id=69132&action=edit dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #3 from mdrslmr@t-online.de --- Created attachment 69133 --> https://bugs.freedesktop.org/attachment.cgi?id=69133&action=edit Xorg.0.log
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #4 from mdrslmr@t-online.de --- The dmesg and xorg log files are done with the top of the 9.0 branch 5fe5aa8e55a8db0b80f6ff9838bad47ce0406fd0
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #5 from mdrslmr@t-online.de --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #6 from Alex Deucher agd5f@yahoo.com --- You can just checkout a commit on master around the time 8.0 was branched.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #7 from mdrslmr@t-online.de --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=56405
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |klausenbusk@hotmail.com
--- Comment #8 from Alex Deucher agd5f@yahoo.com --- *** Bug 56464 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=56405
Andreas Boll andreas.boll.dev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|Drivers/DRI/Radeon |Drivers/Gallium/r600
https://bugs.freedesktop.org/show_bug.cgi?id=56405
runetmember@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |runetmember@gmail.com
--- Comment #9 from runetmember@gmail.com --- *** Bug 56666 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #10 from mdrslmr@t-online.de --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #11 from mdrslmr@t-online.de --- Created attachment 69497 --> https://bugs.freedesktop.org/attachment.cgi?id=69497&action=edit script to build libraries and drivers
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #12 from Michel Dänzer michel@daenzer.net --- What are the compile errors?
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #13 from Michael Dressel mdrslmr@t-online.de --- Created attachment 69640 --> https://bugs.freedesktop.org/attachment.cgi?id=69640&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #14 from Michel Dänzer michel@daenzer.net --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #15 from Michael Dressel mdrslmr@t-online.de --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #16 from Michael Dressel mdrslmr@t-online.de --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #17 from Michael Dressel mdrslmr@t-online.de --- (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 "
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #18 from Michel Dänzer michel@daenzer.net --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #19 from Michael Dressel mdrslmr@t-online.de --- 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?
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #20 from Alex Deucher agd5f@yahoo.com --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #21 from Michel Dänzer michel@daenzer.net --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #22 from Michael Dressel mdrslmr@t-online.de --- Created attachment 70326 --> https://bugs.freedesktop.org/attachment.cgi?id=70326&action=edit bisect log
I think all the information can be derived by replaying bisect log information from the file I attached.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #23 from Michael Dressel mdrslmr@t-online.de --- Created attachment 70327 --> https://bugs.freedesktop.org/attachment.cgi?id=70327&action=edit patch I used for compilation
This is git diff -p output showing the patches I applied to get some thing compiled.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #24 from Michel Dänzer michel@daenzer.net --- (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?
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #25 from Michael Dressel mdrslmr@t-online.de --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #26 from Michel Dänzer michel@daenzer.net --- (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?
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #27 from Michael Dressel mdrslmr@t-online.de --- (In reply to comment #26)
(In reply to comment #25) LIBGL_DEBUG=verbose glxinfo | grep render
I don't have glxinfo
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #28 from Michael Dressel mdrslmr@t-online.de --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #29 from Michael Dressel mdrslmr@t-online.de --- (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
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #30 from Michael Dressel mdrslmr@t-online.de --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #31 from Michel Dänzer michel@daenzer.net --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #32 from Michael Dressel mdrslmr@t-online.de --- Created attachment 70453 --> https://bugs.freedesktop.org/attachment.cgi?id=70453&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #33 from Michael Dressel mdrslmr@t-online.de --- Created attachment 70454 --> https://bugs.freedesktop.org/attachment.cgi?id=70454&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #34 from Michael Dressel mdrslmr@t-online.de --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #35 from Alex Deucher agd5f@yahoo.com --- To confirm, does: Option "ColorTiling2D" "false" in the device section of your xorg.conf also fix the issues?
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #36 from Michael Dressel mdrslmr@t-online.de --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #37 from runetmember@gmail.com --- For me "ColorTiling2D" "false" doesn't help too.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #38 from Michael Dressel mdrslmr@t-online.de --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #39 from Alex Deucher agd5f@yahoo.com --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #40 from klausenbusk@hotmail.com --- Any update?
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #41 from Jerome Glisse glisse@freedesktop.org --- Created attachment 71284 --> https://bugs.freedesktop.org/attachment.cgi?id=71284&action=edit Patch gpu pipe
Does this kernel patch fix the issue ?
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #42 from Alex Deucher agd5f@yahoo.com --- case CHIP_SUMO2: - rdev->config.evergreen.num_ses = 1; + rdev->config.evergreen.num_ses = 2;
None of the APUs have multiple SEs.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #43 from klausenbusk@hotmail.com --- (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?
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #44 from Alex Deucher agd5f@yahoo.com --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #45 from Michael Dressel mdrslmr@t-online.de --- (In reply to comment #41)
Created attachment 71284 [details] [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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johannes.hirte@fem.tu-ilmen | |au.de
--- Comment #46 from Alex Deucher agd5f@yahoo.com --- *** Bug 56720 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=56405
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kphillisjr@gmail.com
--- Comment #47 from Alex Deucher agd5f@yahoo.com --- *** Bug 58115 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #48 from klausenbusk@hotmail.com --- (In reply to comment #41)
Created attachment 71284 [details] [review] Patch gpu pipe
Does this kernel patch fix the issue ?
Does this patch get into kernel 3.8?
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #49 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #48)
Does this patch get into kernel 3.8?
Yes. It will be in 3.8 and the stable kernels.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adamreichold@myopera.com
--- Comment #50 from Alex Deucher agd5f@yahoo.com --- *** Bug 58634 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=56405
Florian Mickler florian@mickler.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |florian@mickler.org
--- Comment #51 from Florian Mickler florian@mickler.org --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #52 from Johannes Hirte johannes.hirte@fem.tu-ilmenau.de --- Fix works for me.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #53 from runetmember@gmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
Michael Dressel mdrslmr@t-online.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #54 from Michael Dressel mdrslmr@t-online.de --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=56405
Mike Lothian mike@fireburn.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mike@fireburn.co.uk
--- Comment #55 from Mike Lothian mike@fireburn.co.uk --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #56 from Mike Lothian mike@fireburn.co.uk --- Created attachment 75082 --> https://bugs.freedesktop.org/attachment.cgi?id=75082&action=edit Dmesg output
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #57 from Mike Lothian mike@fireburn.co.uk --- 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
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org