Bug 60389 - AMD a6-5400K Black Edition with igx 7540D artifacts
AMD a6-5400K Black Edition with igx 7540D artifacts
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/Radeon
7.7 (2012.06)
x86-64 (AMD64) All
: medium normal
Assigned To: xf86-video-ati maintainers
Xorg Project Team
:
: 63997 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-07 02:39 UTC by p00h
Modified: 2014-01-16 21:16 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg.log (6.75 KB, text/plain)
2013-02-07 15:05 UTC, p00h
no flags Details
glxinfo (34.10 KB, text/plain)
2013-02-07 15:07 UTC, p00h
no flags Details
xorg (89.66 KB, text/plain)
2013-02-07 15:08 UTC, p00h
no flags Details
xorg.log (89.66 KB, text/plain)
2013-02-07 15:10 UTC, p00h
no flags Details
dmesg archlinux (7.64 KB, text/plain)
2013-02-07 15:57 UTC, p00h
no flags Details
lspci archlinux (276 bytes, text/plain)
2013-02-07 16:00 UTC, p00h
no flags Details
xorg arclinux (8.11 KB, text/plain)
2013-02-07 16:00 UTC, p00h
no flags Details
Xorg.log archlinux (47.18 KB, text/plain)
2013-02-07 16:00 UTC, p00h
no flags Details
video file (2.06 MB, video/3gpp)
2013-02-07 20:04 UTC, p00h
no flags Details
good apu (1.41 MB, image/jpeg)
2013-02-07 20:06 UTC, p00h
no flags Details
bad apu (1.25 MB, image/jpeg)
2013-02-07 20:10 UTC, p00h
no flags Details
lspci AMD A4 4000 Radeon HD 4850D (2.34 KB, text/plain)
2013-11-09 11:05 UTC, Tony Ducrocq
no flags Details
possible fix (1.16 KB, patch)
2013-12-04 16:09 UTC, Alex Deucher
no flags Details | Splinter Review
possible fix (1.73 KB, patch)
2013-12-17 17:01 UTC, Alex Deucher
no flags Details | Splinter Review
possible fix (1.72 KB, patch)
2013-12-18 02:06 UTC, FatalSaint
no flags Details | Splinter Review
possible fix (3.71 KB, patch)
2013-12-18 14:35 UTC, Alex Deucher
no flags Details | Splinter Review
possible fix (2.61 KB, patch)
2013-12-18 17:35 UTC, Alex Deucher
no flags Details | Splinter Review
possible fix (1.35 KB, patch)
2013-12-18 18:09 UTC, Alex Deucher
no flags Details | Splinter Review
possible fix (2.66 KB, patch)
2013-12-18 22:07 UTC, Alex Deucher
no flags Details | Splinter Review
possible fix (2.52 KB, patch)
2013-12-18 23:16 UTC, Alex Deucher
no flags Details | Splinter Review
minimal fix (735 bytes, patch)
2013-12-19 01:18 UTC, FatalSaint
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description p00h 2013-02-07 02:39:57 UTC
I have two identical Motherboards Gigabyte Fm2A75-d3h.
First configuration:
[1] 2x 4gb DDR3-1333 + AMD a6-5400k
[2] 2x 4gb DDR-1600 + AMD a6-5400k Black Edition.

All systems ships with absolutely identical images with Arch Linux (Kernel 3.6.9).
X.Org X Server 1.13.2.
xf86-video-ati-7.1.0.

Every system has 3 attached monitors. I'm trying to launch 3 undependent seats.
Every APU have been tested at every motherboard with various memory modules. As a result issues described above depends on APU only.

In addition to arch image all tests have been made at fresh installed Ubuntu 12.10.1 i386.

With [2] configuration system is working rather stable but with much artifacts on desktop. OpenGL applications are flickering and tearing, but not freezes.

With [1] configuration no artefacts detected at all, but OpenGL applications freezes after 5-10 seconds after launch. Only restart of x server can solve this issue.
Comment 1 Alex Deucher 2013-02-07 12:49:47 UTC
Please attach the xorg logs, xorg configs (if you are using one), dmesg outputs, and glxinfo outputs from both systems.
Comment 2 p00h 2013-02-07 15:05:39 UTC
Created attachment 74349 [details]
dmesg.log
Comment 3 p00h 2013-02-07 15:07:31 UTC
Created attachment 74350 [details]
glxinfo

glxinfo
Comment 4 p00h 2013-02-07 15:08:41 UTC
Created attachment 74351 [details]
xorg
Comment 5 p00h 2013-02-07 15:10:45 UTC
Created attachment 74352 [details]
xorg.log
Comment 6 p00h 2013-02-07 15:14:27 UTC
Sorry for posting much comments, i haven't been working with bugzilla yet.

Last attachments belongs to machine [2] with pure installed Ubuntu 12.10.1 with open drivers by default.

root@ubuntu:/var/log# uname -a
Linux ubuntu 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:05:29 UTC 2013 i686 athlon i686 GNU/Linux

Necessary files from second configuration will be posted soon.

Thanks for advance!
Comment 7 Michel Dänzer 2013-02-07 15:28:19 UTC
Please file a second report for the second problem, or this will turn into a mess very quickly.
Comment 8 p00h 2013-02-07 15:57:45 UTC
Created attachment 74355 [details]
dmesg archlinux
Comment 9 p00h 2013-02-07 16:00:11 UTC
Created attachment 74357 [details]
lspci archlinux
Comment 10 p00h 2013-02-07 16:00:28 UTC
Created attachment 74358 [details]
xorg arclinux
Comment 11 p00h 2013-02-07 16:00:46 UTC
Created attachment 74359 [details]
Xorg.log archlinux
Comment 12 p00h 2013-02-07 16:01:41 UTC
I've posted rest of files from Arch Linux image.

multiseat# uname -a
Linux multiseat 3.6.9-1-gpgpu #1 SMP PREEMPT Sat Dec 8 00:12:32 YEKT 2012 i686 GNU/Linux
Comment 13 Alex Deucher 2013-02-07 17:01:39 UTC
It looks like you have 3 boards in each system.  Does it work ok with a single board?
Comment 14 p00h 2013-02-07 17:03:18 UTC
Each system has 2 pci-e devices except APU. System works perfectly using them.
Comment 15 Alex Deucher 2013-02-07 17:07:57 UTC
(In reply to comment #14)
> Each system has 2 pci-e devices except APU. System works perfectly using
> them.

Does the APU work ok without the PCIE cards installed?
Comment 16 p00h 2013-02-07 17:11:05 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > Each system has 2 pci-e devices except APU. System works perfectly using
> > them.
> 
> Does the APU work ok without the PCIE cards installed?

No, no matter. APU works equally both with and without PCIE cards.
Comment 17 Alex Deucher 2013-02-07 17:29:27 UTC
(In reply to comment #16)
> No, no matter. APU works equally both with and without PCIE cards.

So all the cards (APU and PCIE cards) work fine by themselves?  Is the problem just when you try and use all 3 at the same time?
Comment 18 p00h 2013-02-07 17:40:17 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > No, no matter. APU works equally both with and without PCIE cards.
> 
> So all the cards (APU and PCIE cards) work fine by themselves?  Is the
> problem just when you try and use all 3 at the same time?

PCIE cards themselves works fine anytime. APU fails to work correctly anytime. No matter there are any PCIE cards installed or not.
Comment 19 Alex Deucher 2013-02-07 17:50:19 UTC
Does disabling 2D Colortiling help?  Add:

Option "ColorTiling2D" "false"

in the APU device section of your xorg.conf.

You might also try updating your xf86-video-ati package to 7.0.0 or newer.
Comment 20 p00h 2013-02-07 17:55:41 UTC
(In reply to comment #19)
> Does disabling 2D Colortiling help?  Add:
> 
> Option "ColorTiling2D" "false"
I've tried disabling ColorTiling2D already. Nothing have changed.

> You might also try updating your xf86-video-ati package to 7.0.0 or newer.
I have 7.1.0. The latest available in git.
Comment 21 Alex Deucher 2013-02-07 19:13:58 UTC
Can you attach a picture of the problems you are seeing?  Can you try a newer kernel?  3.7 or 3.8?
Comment 22 p00h 2013-02-07 19:44:06 UTC
I have tested much kernels including 3.5.x, 3.7.x, 3.8.x, but 3.6.x gives minimum of artifacts. I dont know how to explain this fact.
There is one important note: current problem detects using a6 5400k BLACK EDITION (!!!) ONLY. If i use a6 5400k with locked multiplier (NOT black edition label) system suits me well. None artifacts detected at all.
Unfortunately i have no ability to attach any pictures or videos right now. Only tomorrow.
Comment 23 p00h 2013-02-07 20:04:04 UTC
Created attachment 74376 [details]
video file
Comment 24 p00h 2013-02-07 20:06:11 UTC
Created attachment 74377 [details]
good apu
Comment 25 p00h 2013-02-07 20:10:16 UTC
Created attachment 74378 [details]
bad apu
Comment 26 p00h 2013-02-07 20:13:10 UTC
i have three of both kinds of apus. 3 a6 5400k and 3 a6 5400k black edition. all of them were tested, so i can be quite sure the problem not in concrete unit. the problem is in black edition.
Comment 27 lgg2lgg2 2013-05-24 20:19:31 UTC
Hello,

The same problem with the same APU A6 5400k on ArchLinux + Gnome 3. Artifacts at the begining. Late (one or two minutes after) the fonts goes to blocks.
Comment 28 p00h 2013-05-25 13:39:57 UTC
(In reply to comment #27)
> Hello,
> 
> The same problem with the same APU A6 5400k on ArchLinux + Gnome 3.
> Artifacts at the begining. Late (one or two minutes after) the fonts goes to
> blocks.

Hi there!
There is only one dirty workaround we have found.
You can see speciefic vendor codes on every chip. The second string is the most important for our needs.
On "good_apu" (see attachments) first symbols are "GA...", and "GB..." on the "bad_apu". These probably means country or region where this concrete unit was produced. GA is for Malaysia or Taiwan, GB is for China. I dont know how units have so much differences, but they are. I have tested more than 20 units of both kinds, and 90% of GB usually gives me bad pictures and artifacts. 100% of GA works great.
Comment 29 adam 2013-06-10 03:57:00 UTC
I am seeing this too, black edition.  The chipset is A85X here, Gigabyte with BIOS emulation.
Comment 30 stevenvandenbrandenstift 2013-06-16 08:42:33 UTC
i confirm this bug also on a  AMD A4-5300 APU
Comment 31 bgunteriv 2013-10-06 15:33:19 UTC
I am getting a lot of artifacts in XBMC GUI. 
videos play fine, if i install lubuntu the display is fine.

i only use this machine for xbmc though.

here are some logs:

http://paste.ubuntu.com/6192150/
http://paste.ubuntu.com/6192153/
http://paste.ubuntu.com/6192155/
http://paste.ubuntu.com/6192158/
http://paste.ubuntu.com/6192162/

i don't use any particular xorg.conf
i just created one to turn off Accel -- which works, but then both my CPU's peak above 90%. which makes XBMC menus very slow.
Comment 32 Tony Ducrocq 2013-11-09 11:05:27 UTC
Created attachment 88925 [details]
lspci AMD A4 4000 Radeon HD 4850D

I can confirm this bug with AMD A4 4000 and Radeon HD 4850D
Comment 33 Vladi 2013-11-14 05:14:46 UTC
patched kernel 3.12.0 with drm fixes for 3.13 from http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.13 with no changes to the GL flicker in xbmc or glxgears
Comment 34 kokoBo 2013-11-23 13:03:02 UTC
Hi p00h,
I use a Fm2A75-d3h mobo with AMD a6-5400k Black Edition.
I tested the latest kernel 3.13rc which been released on NOV 22.
All problems are still existing.

Please fix it soon, this is so frustrating.

Thanks.
Comment 35 Vladi 2013-11-28 17:07:58 UTC
same issues with 3.13-rc1 + mesa from git + glamor from git + xbmc from git + ati xorg driver from git
Comment 36 sda 2013-12-04 14:27:33 UTC
Can confirm the same on A4 4000 + FM2A75M-DGS.
Any pointers where to start looking ?

Tried Ubuntu 13.04, 13.10, and 13.10 + Oibaf latest.
fglrx works fine.

Btw. EGL + openglesv2 with gallium + r600 on framebuffer suffer same problem (i.e. without any X11).
Comment 37 Alex Deucher 2013-12-04 16:09:16 UTC
Created attachment 90247 [details] [review]
possible fix

Does this patch help?
Comment 38 Alex Deucher 2013-12-04 16:15:06 UTC
*** Bug 63997 has been marked as a duplicate of this bug. ***
Comment 39 Andreas Galauner 2013-12-04 22:25:42 UTC
(In reply to comment #37)
> Created attachment 90247 [details] [review] [review]
> possible fix
> 
> Does this patch help?

I just applied the patch on an A4-4000 system to a Gentoo kernel 3.12.0 and it didn't fix the artefacts for me. :(

Installed packages:
libdrm-2.4.49-r1
mesa-9.2.4
X.Org 1.14.3
xf86-video-ati-7.2.0
Comment 40 p00h 2013-12-05 03:15:34 UTC
(In reply to comment #37)
> Created attachment 90247 [details] [review] [review]
> possible fix
> 
> Does this patch help?

Didnt help for me too. Im using latest drivers and 3.11.6 kernel at archlinux.
Comment 41 david 2013-12-05 14:18:55 UTC
I can confirm the problem with amd a4 5300K
Comment 42 FatalSaint 2013-12-05 14:44:51 UTC
(In reply to comment #37)
> Created attachment 90247 [details] [review] [review]
> possible fix
> 
> Does this patch help?

Compiled the patch against both 3.12rc7 and 3.13rc2-1 kernels.  Unfortunately, did not resolve the issue in either.

AMD A6-6400k w/ Radeon 8470D

If any additional information is desired let me know.
Comment 43 DeRonny 2013-12-16 21:07:44 UTC
I have the same problem here with AMD A6-6400k, Radeon 8470D.
Comment 44 bgunteriv 2013-12-17 16:08:07 UTC
https://bugs.freedesktop.org/attachment.cgi?id=86939

this patch has done the most, so far, to resolve this issue.

i know there's lot of work to make 3.13 kernel a success... are there any updates to this issue?
Comment 45 Alex Deucher 2013-12-17 16:51:17 UTC
(In reply to comment #44)
> https://bugs.freedesktop.org/attachment.cgi?id=86939
> 
> this patch has done the most, so far, to resolve this issue.

What do you mean by "the most?"  Does changing the value from of rdev->config.cayman.max_hw_contexts from 4 to 2 help?
Comment 46 Alex Deucher 2013-12-17 17:01:33 UTC
Created attachment 90885 [details] [review]
possible fix

Does this patch help?  If not, you might try adjusting values of the members of rdev->config.cayman further.
Comment 47 bgunteriv 2013-12-17 17:04:45 UTC
(In reply to comment #46)
> Created attachment 90885 [details] [review] [review]
> possible fix
> 
> Does this patch help?  If not, you might try adjusting values of the members
> of rdev->config.cayman further.

without the aforementioned patch, I could not read pretty much anything on my XBMC GUI screen, and navigating was just based on memory of where things were.
with this particular patch applied, I can at least read and navigate my XBMC GUI. the artifacts are still there... but it's MUCH better.

i will try to make these adjustments, and get back to you.
i'm currently reverting back to 3.13-rc3. i had problems compiling the 3.13-rc4
Comment 48 bgunteriv 2013-12-17 18:50:09 UTC
(In reply to comment #46)
> Created attachment 90885 [details] [review] [review]
> possible fix
> 
> Does this patch help?  If not, you might try adjusting values of the members
> of rdev->config.cayman further.

having trouble applying this patch.

keeps giving me this error:
error: patch failed: drivers/gpu/drm/radeon/ni.c:919
error: drivers/gpu/drm/radeon/ni.c: patch does not apply

suggestions?
Comment 49 Alex Deucher 2013-12-17 18:57:41 UTC
(In reply to comment #48)
> (In reply to comment #46)
> > Created attachment 90885 [details] [review] [review] [review]
> > possible fix
> > 
> > Does this patch help?  If not, you might try adjusting values of the members
> > of rdev->config.cayman further.
> 
> having trouble applying this patch.
> 
> keeps giving me this error:
> error: patch failed: drivers/gpu/drm/radeon/ni.c:919
> error: drivers/gpu/drm/radeon/ni.c: patch does not apply
> 
> suggestions?

Remove any previous patches you may have applied.
Comment 50 FatalSaint 2013-12-18 00:29:27 UTC
(In reply to comment #46)
> Created attachment 90885 [details] [review] [review]
> possible fix
> 
> Does this patch help?  If not, you might try adjusting values of the members
> of rdev->config.cayman further.

This makes it really bad.  Screen goes either completely white/snowy or completely black with small snow spots on it.  It seems related to UVD errors, but I've always had UVD errors on boot and the GUI still showed, now there's nothing.

[drm:cayman_startup] *ERROR* radeon: failed initializing UVD (-1).
drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!!

I am going to play with the numbers and the other patch and see if I can make a difference.
Comment 51 FatalSaint 2013-12-18 00:56:40 UTC
(In reply to comment #45)
> (In reply to comment #44)
> > https://bugs.freedesktop.org/attachment.cgi?id=86939
> > 
> > this patch has done the most, so far, to resolve this issue.
> 
> What do you mean by "the most?"  Does changing the value from of
> rdev->config.cayman.max_hw_contexts from 4 to 2 help?

Setting this value to 2 in the attached patch makes a *significant* improvement.  About half of my screens are now tear/artifact free.  The artifacts come back on screens that seem to some overlay or transparency (like certain text areas in XBMC screens).
Comment 52 FatalSaint 2013-12-18 02:06:27 UTC
Created attachment 90907 [details] [review]
possible fix

I'm sure more testing is needed.. but the attached patch worked for me.  Artifacts are now not on any screen in XBMC that I've tried yet.

I basically just took most of Alex's value's and halved them (which would be 1/4 the original).. and also changed insts and channel_caches.
Comment 53 FatalSaint 2013-12-18 02:07:50 UTC
I should mention that I am using the 3.13rc3 kernel.  Don't know if that matters.
Comment 54 stevenvandenbrandenstift 2013-12-18 13:03:48 UTC
(In reply to comment #53)
> I should mention that I am using the 3.13rc3 kernel.  Don't know if that
> matters.

tested here on a 3.12-5 archlinux kernel (latest at time of writing)
i only aplied the possible fix of FatalSaint.

I can confuirm that glxgears and dungien siege 2 (a game in wine) runs perfect along with my xfce4 envirement.

Although more testing could be needed, this patch does the trick for me too!
Comment 55 Alex Deucher 2013-12-18 14:33:11 UTC
Can you narrow down to just which specific values need to be changed?
Comment 56 Alex Deucher 2013-12-18 14:35:55 UTC
Created attachment 90928 [details] [review]
possible fix

Does this patch work any better?
Comment 57 Vladi 2013-12-18 17:19:23 UTC
Patched my 3.13-rc4 with latest patch by Alex and no more seizures :) Thanks!
Comment 58 david 2013-12-18 17:22:18 UTC
great news!

I'm a bit noob with this. Is this going to be in master? I mean, with apt-get upgrade...
if not, how could I patch my system?
Comment 59 Vladi 2013-12-18 17:35:00 UTC
What does this patch actually do? Does this mean our A6 black edition is less black then the others made in China? Whats the difference?
Comment 60 Alex Deucher 2013-12-18 17:35:57 UTC
Created attachment 90939 [details] [review]
possible fix

How about this one?
Comment 61 Vladi 2013-12-18 17:38:39 UTC
David you will need to either compile your own kernel or get the latest kernel once Alex merges this patch into 3.13.0-rc5 from an ubuntu ppa if you use ubuntu.
Comment 62 Vladi 2013-12-18 17:46:04 UTC
Alex, your latest patch is better then before, but there is still flicker and some artifacts.
Comment 63 Alex Deucher 2013-12-18 18:09:58 UTC
Created attachment 90940 [details] [review]
possible fix

How about this one?  If it works, can you try adjusting the max_pipes_per_simd, sx_num_of_sets, max_hw_contexts to see which combinations work?  E.g.,

v1:
rdev->config.cayman.max_pipes_per_simd = 2;
rdev->config.cayman.sx_num_of_sets = 2;
rdev->config.cayman.max_hw_contexts = 2;

v2:
rdev->config.cayman.max_pipes_per_simd = 4;
rdev->config.cayman.sx_num_of_sets = 2;
rdev->config.cayman.max_hw_contexts = 2;

v3:
rdev->config.cayman.max_pipes_per_simd = 2;
rdev->config.cayman.sx_num_of_sets = 4;
rdev->config.cayman.max_hw_contexts = 2;

v4:
rdev->config.cayman.max_pipes_per_simd = 2;
rdev->config.cayman.sx_num_of_sets = 2;
rdev->config.cayman.max_hw_contexts = 4;

v5:
rdev->config.cayman.max_pipes_per_simd = 4;
rdev->config.cayman.sx_num_of_sets = 4;
rdev->config.cayman.max_hw_contexts = 2;

v6:
rdev->config.cayman.max_pipes_per_simd = 2;
rdev->config.cayman.sx_num_of_sets = 4;
rdev->config.cayman.max_hw_contexts = 4;

v7:
rdev->config.cayman.max_pipes_per_simd = 4;
rdev->config.cayman.sx_num_of_sets = 2;
rdev->config.cayman.max_hw_contexts = 4;
Comment 64 Alex Deucher 2013-12-18 18:16:52 UTC
(In reply to comment #59)
> What does this patch actually do? Does this mean our A6 black edition is
> less black then the others made in China? Whats the difference?

It adjusts some of the chip specific parameters.  There are several versions of trinity/richland parts with different sized GPUs on them.  Some of the parameters are wrong from some of the parts.  Nothing to do with black edition or not.
Comment 65 bgunteriv 2013-12-18 18:31:34 UTC
(In reply to comment #52)
> Created attachment 90907 [details] [review] [review]
> possible fix
> 
> I'm sure more testing is needed.. but the attached patch worked for me. 
> Artifacts are now not on any screen in XBMC that I've tried yet.
> 
> I basically just took most of Alex's value's and halved them (which would be
> 1/4 the original).. and also changed insts and channel_caches.

this one worked for me!
thanks, fatalsaint... great job, everyone!!!
Comment 66 Alex Deucher 2013-12-18 18:39:24 UTC
(In reply to comment #65)
> (In reply to comment #52)
> > Created attachment 90907 [details] [review] [review] [review]
> > possible fix
> > 
> > I'm sure more testing is needed.. but the attached patch worked for me. 
> > Artifacts are now not on any screen in XBMC that I've tried yet.
> > 
> > I basically just took most of Alex's value's and halved them (which would be
> > 1/4 the original).. and also changed insts and channel_caches.
> 
> this one worked for me!
> thanks, fatalsaint... great job, everyone!!!

Please try my suggestions in comment 63 so we can narrow down exactly which parameters need to be changed.
Comment 67 stevenvandenbrandenstift 2013-12-18 18:45:43 UTC
well ill try the combinations of comment 63 , is there any way to only recompile that file without recompiling the total kernel?
Comment 68 Alex Deucher 2013-12-18 18:47:42 UTC
(In reply to comment #67)
> well ill try the combinations of comment 63 , is there any way to only
> recompile that file without recompiling the total kernel?

The kernel will only rebuild source files that have changed.
Comment 69 FatalSaint 2013-12-18 18:55:49 UTC
(In reply to comment #68)
> (In reply to comment #67)
> > well ill try the combinations of comment 63 , is there any way to only
> > recompile that file without recompiling the total kernel?
> 
> The kernel will only rebuild source files that have changed.

This is how I've been doing it.  As long as you rebuild within the same source tree it only takes a couple minutes to recompile and test.  I unfortunately can't do it until I get home tonight.  Hopefully by then you guys will have narrowed it down!
Comment 70 stevenvandenbrandenstift 2013-12-18 19:40:24 UTC
well i use the makepkg system from archlinux to rebuild the package with a patch, since i have not figured out how to apply a different patch without rebuilding it will take me a while, so if someone else can do it quicker pleas go ahead
Comment 71 FatalSaint 2013-12-18 19:46:12 UTC
(In reply to comment #70)
> well i use the makepkg system from archlinux to rebuild the package with a
> patch, since i have not figured out how to apply a different patch without
> rebuilding it will take me a while, so if someone else can do it quicker
> pleas go ahead

I do the same thing.  I have manually downloaded the linux-mainline PKGBUILD and included files from AUR that I've modified to use the 3.13r3 kernel with this patch (I think I grabbed it when it was 13rc1 or 2, I see it's updated now to rc4).

As long as I don't clear out the files, and just run makepkg from inside the same directory, it untars the kernel tarball but it doesn't overwrite the compiled pieces.  Seems to work, it only recompiled the files that change for me.  

The first time I do it in a clean directory it takes a long time, but subsequent runs are fine as long as I don't start fresh.
Comment 72 Henrik Brunberg 2013-12-18 20:50:38 UTC
fritsch compiled v7 for me and i tried it still artifacts but not as bad on a amd A6-6400k cpu
Comment 73 Henrik Brunberg 2013-12-18 21:05:16 UTC
v1 gave me artifacts too
Comment 74 stevenvandenbrandenstift 2013-12-18 21:18:52 UTC
i have the following results on the latest archlinux core repo kernel:
on a A4-5300 apu,

the fix by FatalSaint fixed all the issues, in glxgears and in dugeon siege 2
the latest fix (comment 63):

checked v1 so far , glxgears goes nice, but dungeon siege 2 get artifacts and glither althought much less then without patch

ill run the other later because it seems i still cannot rerun the compiling with only the new part but thats not for here to discuss
Comment 75 stevenvandenbrandenstift 2013-12-18 21:28:44 UTC
the values that are being asked to test are the same on both but following differ:

working patch (fAtalSaint)                      comment 63 patch
rdev->config.cayman.max_gs_threads = 8;               32
rdev->config.cayman.max_stack_entries = 128;          512
rdev->config.cayman.sx_num_of_sets = 2;               8
rdev->config.cayman.sx_max_export_size = 64;          256
rdev->config.cayman.sx_max_export_pos_size = 16;      64
rdev->config.cayman.sx_max_export_smx_size = 48;      192

Could i be correct that because path v1 include the same testing values as the FatalSaint patch , the issue lays with one of the upper value, or could it be that there is another working solution without adjusting the values above?

anyway i will test version 2 now
Comment 76 stevenvandenbrandenstift 2013-12-18 21:40:00 UTC
ow seems like this was in the FatalSaint patch too and not in the comment 63,
rdev->config.cayman.sc_hiz_tile_fifo_size = 0x30;

to be complete
Comment 77 Alex Deucher 2013-12-18 21:57:31 UTC
If v1 doesn't help, there's no need to try the others.
Comment 78 Alex Deucher 2013-12-18 22:07:16 UTC
Created attachment 90949 [details] [review]
possible fix

How about this one?
Comment 79 Henrik Brunberg 2013-12-18 22:13:34 UTC
hi this is video of v1 http://brunberg.nu/brunis/artifacts.MOV

v2 is the same lower right corner but have larger artifacts then v1
Comment 80 FatalSaint 2013-12-18 23:06:03 UTC
(In reply to comment #78)
> Created attachment 90949 [details] [review] [review]
> possible fix
> 
> How about this one?

Yes.  This one works as well.  At least it appears to for me.
Comment 81 Alex Deucher 2013-12-18 23:16:58 UTC
Created attachment 90957 [details] [review]
possible fix

(In reply to comment #80)
> (In reply to comment #78)
> > Created attachment 90949 [details] [review] [review] [review]
> > possible fix
> > 
> > How about this one?
> 
> Yes.  This one works as well.  At least it appears to for me.

Great.  How about this one?
Comment 82 bgunteriv 2013-12-18 23:21:26 UTC
(In reply to comment #78)
> Created attachment 90949 [details] [review] [review]
> possible fix
> 
> How about this one?

yes, this one also works for me.

a6-6400 black edition
Comment 83 FatalSaint 2013-12-18 23:35:01 UTC
(In reply to comment #81)
> Created attachment 90957 [details] [review] [review]
> possible fix
> 
> (In reply to comment #80)
> > (In reply to comment #78)
> > > Created attachment 90949 [details] [review] [review] [review] [review]
> > > possible fix
> > > 
> > > How about this one?
> > 
> > Yes.  This one works as well.  At least it appears to for me.
> 
> Great.  How about this one?

Yes.  Also good.

I am also making kernels in between checking the values that were in my original fix and resetting them to defaults one by one.
Comment 84 Henrik Brunberg 2013-12-18 23:38:58 UTC
this new one works fine for me too ;)
AMD A6-6400k cpu
Comment 85 Mirko 2013-12-18 23:47:09 UTC
Seems right now on my APU [1002:9993].
Comment 86 bgunteriv 2013-12-18 23:58:05 UTC
(In reply to comment #81)
> Created attachment 90957 [details] [review] [review]
> possible fix
> 
> (In reply to comment #80)
> > (In reply to comment #78)
> > > Created attachment 90949 [details] [review] [review] [review] [review]
> > > possible fix
> > > 
> > > How about this one?
> > 
> > Yes.  This one works as well.  At least it appears to for me.
> 
> Great.  How about this one?

yup... i have success with this patch as well.
Comment 87 FatalSaint 2013-12-19 01:18:52 UTC
Created attachment 90961 [details] [review]
minimal fix

Ok, I've narrowed it down to these 3 specific changes:
rdev->config.cayman.sx_max_export_size = 64;
rdev->config.cayman.sx_max_export_smx_size = 48;
rdev->config.cayman.max_hw_contexts = 2;

See attached patch.. my system seems to run well with it.  I'm building a completely fresh kernel with it now just to be sure.  

If I change any of those back to their original values (256, 192, 8 respectively) then different aspects of the artifacts returns.

I have not tried any values in between yet to see how high they can go before artifacts become a problem.
Comment 88 FatalSaint 2013-12-19 01:26:03 UTC
Ok, comparing these results with your latest patch Alex, implies that these can be set to the following without issues:

rdev->config.cayman.sx_max_export_size = 128;
rdev->config.cayman.sx_max_export_smx_size = 96;
rdev->config.cayman.max_hw_contexts = 4;

Though I haven't tested that directly yet.
Comment 89 FatalSaint 2013-12-19 04:18:19 UTC
Well, didn't work.

These need to stay this:
		rdev->config.cayman.sx_max_export_smx_size = 48;
		rdev->config.cayman.max_hw_contexts = 2;

If you're only changing the 3.  

But rdev->config.cayman.sx_max_export_size can be increased to 128.

So there must be some magic with the other 2 items you're changing in yours to allow these 2 to increase.  

Seems like the Patch in Comment 81 is the best one.
Comment 90 Mirko 2013-12-19 08:28:14 UTC
This is the working config for me [1002:9993]:

+			rdev->config.cayman.sx_num_of_sets = 4;
+			rdev->config.cayman.max_hw_contexts = 4;
+			rdev->config.cayman.sx_max_export_size = 128;
+			rdev->config.cayman.sx_max_export_pos_size = 32;
+			rdev->config.cayman.sx_max_export_smx_size = 96;

Changing any of rdev->config.cayman.sx_max_export_ artifacts come back.
Comment 91 Alex Deucher 2013-12-19 15:21:08 UTC
(In reply to comment #90)
> This is the working config for me [1002:9993]:
> 
> +			rdev->config.cayman.sx_num_of_sets = 4;
> +			rdev->config.cayman.max_hw_contexts = 4;
> +			rdev->config.cayman.sx_max_export_size = 128;
> +			rdev->config.cayman.sx_max_export_pos_size = 32;
> +			rdev->config.cayman.sx_max_export_smx_size = 96;
> 
> Changing any of rdev->config.cayman.sx_max_export_ artifacts come back.

Does the patch in comment 81 work for you as is or did you also have to change sx_num_of_sets?
Comment 92 stevenvandenbrandenstift 2013-12-19 20:19:57 UTC
for me the patch in comment 81 works great , glxgears+ dungeon siege working without issues,

on a A4-5300 APU,
thanks a lot! ,
will i make the 3.13 kernel release?
Comment 93 Mirko 2013-12-19 20:38:08 UTC
(In reply to comment #91)
> (In reply to comment #90)
> > This is the working config for me [1002:9993]:
> > 
> > +			rdev->config.cayman.sx_num_of_sets = 4;
> > +			rdev->config.cayman.max_hw_contexts = 4;
> > +			rdev->config.cayman.sx_max_export_size = 128;
> > +			rdev->config.cayman.sx_max_export_pos_size = 32;
> > +			rdev->config.cayman.sx_max_export_smx_size = 96;
> > 
> > Changing any of rdev->config.cayman.sx_max_export_ artifacts come back.
> 
> Does the patch in comment 81 work for you as is or did you also have to
> change sx_num_of_sets?

Using rdev->config.cayman.sx_num_of_sets = 8; also works great.

Just downloading 3.12.5 to make a clean patch (now I'm on 3.11).
Comment 94 Jan Schröter 2013-12-20 03:47:06 UTC
I can confirm - no artifacts with linux 3.12.5 and patch from comment 81.

AMD A4-4000 APU
Comment 95 david 2013-12-22 20:28:15 UTC
Great work guys!

anyone can merge this patch in a kernel for ubuntu? I would really apreciate!
Comment 97 p00h 2013-12-24 13:32:29 UTC
Good! Good! Gooood news!
Thanx a lot to everyone who've been working hard to solve this problem!
Cheers!
Comment 98 spike 2014-01-16 18:35:45 UTC
Hi, is the patch from #81 part of the latest rc?
Comment 99 Alex Deucher 2014-01-16 19:07:23 UTC
Patch is upstream in 3.13, and should be showing up in stable kernels as well:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e2f6c88fb903e123edfd1106b0b8310d5117f774
Comment 100 spike 2014-01-16 21:16:59 UTC
(In reply to comment #99)
> Patch is upstream in 3.13, and should be showing up in stable kernels as
> well:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=e2f6c88fb903e123edfd1106b0b8310d5117f774

Thanks for your reply! I just compiled the latest kernel and got rid of catalyst.
I'm finally able to use my APU with the open-source driver. You don't know how much I have to thank you!! :)