Bug 86038

Created attachment 109135 [details]
Minor visual corruption with fglrx 14.9

This screenshot shows the corrruption I see in the same scene with a fglrx 14.9 (on a 3.16 kernel, since fglrx won't work with 3.18-rc1, some module compilation failure due to ACPI changes). This kin of corruption was expected, when reading the patch notes for Dreamfall Chapters and the FAQ.

I've updated Mesa and LLVM, but that didn't help. The new stack is detailed below.
I forgot to write in comment #0, that the first visual corruption (black rectangles flickering in and out of existance) occurs in the main menu.

And I like to add another observation: when you press escape (ie. pause the game) while there's a visual corruption visible like the one depicted in attachment 109134 [details], the amount of corruption is reduced significantly. Not as good as with the proprietary driver, but still way better than in the running game. The pause menu is basically a grey overlay with the menu options onto a "still image" of the scene you've paused in.


My current stack is (Debian testing as a base):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/a6d8413d7c
libdrm: Git:master/00847fa48b
LLVM: SVN:trunk/r221577 (3.6 devel)
X.Org: 2:1.16.1-1
Linux: Git:git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git:v3.18-rc1 + attachment 107451 [details] [review] and attachment 107544 [details] [review]
Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
> 9e05820da42549ce9c89d147cf1f8e19  /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_ce.bin
> c8bab593090fc54f239c8d7596c8d846  /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_mc.bin
> 3618dbb955d8a84970e262bb2e6d2a16  /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_me.bin
> c000b0fc9ff6582145f66504b0ec9597  /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_mec.bin
> 0643ad24b3beff2214cce533e094c1b7  /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_pfp.bin
> ba6054b7d78184a74602fd81607e1386  /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_rlc.bin
> 11288f635737331b69de9ee82fe04898  /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_sdma.bin
> 284429675a5560e0fad42aa982965fc2  /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_smc.bin
libclc: Git:master/7f6f5bff1f
DDX: 1:7.5.0-1

Can you create an apitrace reproducing the problem?

(In reply to Michel Dänzer from comment #3)
> Can you create an apitrace reproducing the problem?

Sure, here you go: <http://dev.carbon-project.org/debian/mesa.bugs/86038/dreamfall.trace.7z> (file should be completely upload in about 15 minutes after this comment is posted.)
The trace starts in the main menu where I waited until I got one of those flickering rectangles. Afterwards I started a new game and skipped the parts of the intro that don't show any additional errors besides the flickering rectangles. The main part of the trace is the storytime intro sequence where the light shader makes large parts of the screen black. I also pressed pause a few times to show what I meant in comment #2. What you can see in the pause menu is basically what you get with fglrx all the time, maybe a bit worse.

As with the apitrace for bug 84570 I password-protected the download directory to prevent unnecessary downloads (it is rather large), but I gladly provide known Mesa developers with access, just send me a short e-mail.

@Michel: you should have received an e-mail by now with your login information. Feel free to share it internally.


Let me know, if you need something else.

Just FYI:
076faa59f5c748b80a594c55e5e484b3  dreamfall.trace.7z

The file has (packed) 1.6 GB in size and 5.1 GB unpacked.

Created attachment 109252 [details]
Dreamfall printscreen game: game running "ok"

This is how the image of the game, when he is running "ok". This is a printscreen from another player.

Created attachment 109253 [details]
Dreamfall printscreen game: this is how apears in my screen, lot less colors

This is how, the same place, same moment, the images apears in my game.

Created attachment 109254 [details]
Dreamfall printscreen game: lot's of light overshadowing the game

Also, when there is a flash of light in the game, it overshadows when it stays in front of the character.

Sorry, guys, I'm new int the Bugzilla. It looks likes that my attachment whent on without my comment. 

Look, I think I'm having same problems with Dreamfall, except that it don't apear  black screens or black dot, but the light in the game gets "trash". I mean that, in some moments the light don't light up (like in the attachment "Dreamfall printscreen game: this is how apears in my screen, lot less colors", in comment 7, comparing with comment 06). And, the flashlight that overshadows the game, when there's a scene or an place with any flashlight that goes in front of the characters (like in the comment 08).

Sorry, again, if I got to confusing, hope we can resolve this out. Thanks

(In reply to Alexandre from comment #9)
> Sorry, guys, I'm new int the Bugzilla. It looks likes that my attachment
> whent on without my comment. 

No problem, everybody started someday. ;-)

> Look, I think I'm having same problems with Dreamfall, except that it don't
> apear  black screens or black dot, but the light in the game gets "trash". I
> mean that, in some moments the light don't light up (like in the attachment
> "Dreamfall printscreen game: this is how apears in my screen, lot less
> colors", in comment 7, comparing with comment 06). And, the flashlight that
> overshadows the game, when there's a scene or an place with any flashlight
> that goes in front of the characters (like in the comment 08).

I'm not sure, whether this is the same bug or a different one, if I had to guess, I'd say "a different one". Please also keep in mind, that Red Thread Games still has the "there are known issues with shaders on Linux/Mac OS X" in their FAQ at <http://redthreadgames.com/forum/topic/696-dreamfall-chapters-faq-known-issues-please-read-before-posting/>. The colour aberration might just be one such instance.

Anyway, you should add what hardware you have and what versions of Mesa, X, etc. you're running. Maybe you don't use the radeonsi driver at all, but a different one like r600g?

Thanks, Kai.
About my configuration, I use a Ubuntu 14.10 with Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M] (AMD fglrx).

(In reply to Alexandre from comment #11)
> About my configuration, I use a Ubuntu 14.10 with Advanced Micro Devices,
> Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M] (AMD fglrx).

Ok, then this is NOT your bug report. This is only about the free/open-source radeonsi driver. There is no public support for the proprietary fglrx AFAIK. Sorry. (Though you can always switch to the FLOSS driver, which works really great most of the time and has a very responsive team of (AMD) developers behind it.)

Comment on attachment 109253 [details]
Dreamfall printscreen game: this is how apears in my screen, lot less colors

taken with fglrx; not radeonsi

What must I do to adopt or switch in my machine to a open-source driver then?

PS: what's a AFAIK?

Resetting assignee, which Alexandre must have taken by accident.

(In reply to Alexandre from comment #14)
> What must I do to adopt or switch in my machine to a open-source driver then?
> 
> PS: what's a AFAIK?

I've answered both your questions by private e-mail.

Created attachment 109319 [details]
No visual corruption on Intel (Sandybridge)

Just FYI: I had the chance to test the game on an Intel Sandybridge system and there's no visible visual corruption in the same scene (even if it's not the same frame). So the shader is probably ok?

The Mesa version running on that system, is a bit older though: 10.4-devel, commit 5ccdc23a86 (and a build from 2014-09-28).

Happy tidings: with Mesa commit 88fea85f09 and LLVM SVN r222517 (see below for the full stack) I get a lot less visual corruption, than before, see <https://imgur.com/a/8g3Sp>. The Catalyst is still better because there aren't any black areas around the mountain ranges from the intro scene. But in the scene looking out on the palm trees, I'd say, Catalyst/fglrx and radeonsi are now on par.

Long story short: a lot better, but still ways to go. It looks like part of this bug was the same as the later reported bug 86432.

Let me know, if you need something else – like a new apitrace – to debug this.



My current stack is (Debian testing as a base):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/88fea85f09
libdrm: Git:master/00847fa48b
LLVM: SVN:trunk/r222517 (3.6 devel)
X.Org: 2:1.16.1-1
Linux: Git:<git://people.freedesktop.org/~agd5f/linux>:drm-next-3.19-wip/d13184cad0
Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
> 9e05820da42549ce9c89d147cf1f8e19  hawaii_ce.bin
> c8bab593090fc54f239c8d7596c8d846  hawaii_mc.bin
> 3618dbb955d8a84970e262bb2e6d2a16  hawaii_me.bin
> c000b0fc9ff6582145f66504b0ec9597  hawaii_mec.bin
> 0643ad24b3beff2214cce533e094c1b7  hawaii_pfp.bin
> ba6054b7d78184a74602fd81607e1386  hawaii_rlc.bin
> 11288f635737331b69de9ee82fe04898  hawaii_sdma.bin
> 284429675a5560e0fad42aa982965fc2  hawaii_smc.bin
libclc: Git:master/7f6f5bff1f
DDX: 1:7.5.0-1

Since I've updated my stack and there was a new Dreamfall Chapters release (1.1.2), I had a look at the intro scene again. But it looks still like I described in comment #17.

My current stack (Debian testing as a base) is:
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/a2f2eebfdf
libdrm: Git:master/00847fa48b
LLVM: SVN:trunk/r223220 (3.6 devel)
X.Org: 2:1.16.1-1
Linux: Git:<git://people.freedesktop.org/~agd5f/linux>:drm-next-3.19-wip/f66d9660a0
Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
> 9e05820da42549ce9c89d147cf1f8e19  hawaii_ce.bin
> c8bab593090fc54f239c8d7596c8d846  hawaii_mc.bin
> 3618dbb955d8a84970e262bb2e6d2a16  hawaii_me.bin
> c000b0fc9ff6582145f66504b0ec9597  hawaii_mec.bin
> 0643ad24b3beff2214cce533e094c1b7  hawaii_pfp.bin
> ba6054b7d78184a74602fd81607e1386  hawaii_rlc.bin
> 11288f635737331b69de9ee82fe04898  hawaii_sdma.bin
> 284429675a5560e0fad42aa982965fc2  hawaii_smc.bin
libclc: Git:master/229064524b
DDX: Git:master/c9f8f642fd

With my current stack (see below) this bug is fixed. I didn't test it, but could this be related to Marek's fix for the UE4 demos (NaN handling)? Maybe that's a patch you want to backport to the stable branches, then.

My current stack (Debian testing as a base) is:
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/61711316f5
libdrm: Git:master/00847fa48b
LLVM: SVN:trunk/r224079 (3.6 devel)
X.Org: Git:master/6672606420
Linux: Git:<git://people.freedesktop.org/~agd5f/linux>:drm-next-3.19-wip/f66d9660a0
Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
> 9e05820da42549ce9c89d147cf1f8e19  hawaii_ce.bin
> c8bab593090fc54f239c8d7596c8d846  hawaii_mc.bin
> 3618dbb955d8a84970e262bb2e6d2a16  hawaii_me.bin
> c000b0fc9ff6582145f66504b0ec9597  hawaii_mec.bin
> 0643ad24b3beff2214cce533e094c1b7  hawaii_pfp.bin
> ba6054b7d78184a74602fd81607e1386  hawaii_rlc.bin
> 11288f635737331b69de9ee82fe04898  hawaii_sdma.bin
> 284429675a5560e0fad42aa982965fc2  hawaii_smc.bin
libclc: Git:master/0bb35f11b2
DDX: Git:master/c9f8f642fd

(In reply to Kai from comment #19)
> LLVM: SVN:trunk/r224079 (3.6 devel)

Just to set the record straight: I meant r225079. Sorry for the typo.