Bug 60389

Please attach the xorg logs, xorg configs (if you are using one), dmesg outputs, and glxinfo outputs from both systems.

Created attachment 74349 [details]
dmesg.log

Created attachment 74350 [details]
glxinfo

glxinfo

Created attachment 74351 [details]
xorg

Created attachment 74352 [details]
xorg.log

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!

Please file a second report for the second problem, or this will turn into a mess very quickly.

Created attachment 74355 [details]
dmesg archlinux

Created attachment 74357 [details]
lspci archlinux

Created attachment 74358 [details]
xorg arclinux

Created attachment 74359 [details]
Xorg.log archlinux

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

It looks like you have 3 boards in each system.  Does it work ok with a single board?

Each system has 2 pci-e devices except APU. System works perfectly using them.

(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?

(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.

(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?

(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.

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.

(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.

Can you attach a picture of the problems you are seeing?  Can you try a newer kernel?  3.7 or 3.8?

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.

Created attachment 74376 [details]
video file

Created attachment 74377 [details]
good apu

Created attachment 74378 [details]
bad apu

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.

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.

(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.

I am seeing this too, black edition.  The chipset is A85X here, Gigabyte with BIOS emulation.

i confirm this bug also on a  AMD A4-5300 APU

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.

Created attachment 88925 [details]
lspci AMD A4 4000 Radeon HD 4850D

I can confirm this bug with AMD A4 4000 and Radeon HD 4850D

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

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.

same issues with 3.13-rc1 + mesa from git + glamor from git + xbmc from git + ati xorg driver from git

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).

Created attachment 90247 [details] [review]
possible fix

Does this patch help?

*** Bug 63997 has been marked as a duplicate of this bug. ***

(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

(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.

I can confirm the problem with amd a4 5300K

(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.

I have the same problem here with AMD A6-6400k, Radeon 8470D.

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?

(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?

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.

(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

(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?

(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.

(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.

(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).

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.

I should mention that I am using the 3.13rc3 kernel.  Don't know if that matters.

(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!

Can you narrow down to just which specific values need to be changed?

Created attachment 90928 [details] [review]
possible fix

Does this patch work any better?

Patched my 3.13-rc4 with latest patch by Alex and no more seizures :) Thanks!

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?

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?

Created attachment 90939 [details] [review]
possible fix

How about this one?

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.

Alex, your latest patch is better then before, but there is still flicker and some artifacts.

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;

(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.

(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!!!

(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.

well ill try the combinations of comment 63 , is there any way to only recompile that file without recompiling the total kernel?

(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.

(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!

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

(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.

fritsch compiled v7 for me and i tried it still artifacts but not as bad on a amd A6-6400k cpu

v1 gave me artifacts too

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

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

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

If v1 doesn't help, there's no need to try the others.

Created attachment 90949 [details] [review]
possible fix

How about this one?

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

(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.

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?

(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

(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.

this new one works fine for me too ;)
AMD A6-6400k cpu

Seems right now on my APU [1002:9993].

(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.

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.

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.

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.

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.

(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?

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?

(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).

I can confirm - no artifacts with linux 3.12.5 and patch from comment 81.

AMD A4-4000 APU

Great work guys!

anyone can merge this patch in a kernel for ubuntu? I would really apreciate!

Nevermind! fritsch just did it!

It is working really well!

wget https://dl.dropboxusercontent.com/u/55728161/linux-image-3.13.0-rc3-drm-fixes14-v999-na%2B_0.1_amd64.deb https://dl.dropboxusercontent.com/u/55728161/linux-headers-3.13.0-rc3-drm-fixes14-v999-na%2B_0.1_amd64.deb
sudo dpkg -i *rc3-drm-fixes14-v999*deb

http://forum.xbmc.org/showthread.php?tid=174854

Good! Good! Gooood news!
Thanx a lot to everyone who've been working hard to solve this problem!
Cheers!

Hi, is the patch from #81 part of the latest rc?

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

(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!! :)