Bug 77785 - (radeonsi) Some lighting issues in games, textures goes black
Summary: (radeonsi) Some lighting issues in games, textures goes black
Status: RESOLVED INVALID
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: 10.1
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-22 21:23 UTC by smoki
Modified: 2014-07-15 07:44 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
bad case (626.25 KB, image/png)
2014-04-22 21:23 UTC, smoki
Details
good case (890.86 KB, image/png)
2014-04-22 21:28 UTC, smoki
Details
bad case (902.57 KB, image/png)
2014-04-22 21:29 UTC, smoki
Details
good case (swrast) (879.30 KB, image/png)
2014-04-22 21:29 UTC, smoki
Details
good case (swrast) (947.77 KB, image/png)
2014-04-22 21:45 UTC, smoki
Details
STK-black (344.34 KB, image/png)
2014-05-17 13:10 UTC, smoki
Details
Trine 2 - radeon (740.01 KB, image/png)
2014-05-20 00:31 UTC, smoki
Details
Trine 2 - fglrx (1.29 MB, image/png)
2014-05-20 00:32 UTC, smoki
Details
Unigine Sanctuary - radeon (1.05 MB, image/png)
2014-05-20 18:58 UTC, smoki
Details
Unigine Sanctuary - fglrx (1.11 MB, image/png)
2014-05-20 18:59 UTC, smoki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description smoki 2014-04-22 21:23:44 UTC
Created attachment 97777 [details]
bad case

Athlon 5350 (so Radeon R3 or Radeon 8400), current Debian Sid and mesa 10.1. I also tried current mesa git master 10-devel, kernel 3.15-rc3, etc... the same issue with lighting appear. hyperz (enabled/disabled) does not metter here.

 So, in wine with some opengl games (i guess native are also affected, but not found example) for example AirStrike3D or 18 WoS: Pedal to the Metal games. In 18 WoS: Pedal to the Metal. issue appear when i turn on truck headlights, everything beside headlights goes black of course until i turn off headlights... some screenshots i will attach.

 And yeah swrast works OK, fglrx too :)
Comment 1 smoki 2014-04-22 21:28:12 UTC
Created attachment 97778 [details]
good case
Comment 2 smoki 2014-04-22 21:29:02 UTC
Created attachment 97780 [details]
bad case
Comment 3 smoki 2014-04-22 21:29:44 UTC
Created attachment 97781 [details]
good case (swrast)
Comment 4 smoki 2014-04-22 21:45:33 UTC
Created attachment 97786 [details]
good case (swrast)

 Oh, wrong screenshot earlier... forgot to turn on headlights with swrast :). So this good one with swrast, how it need to be ;).
Comment 5 smoki 2014-04-22 22:25:36 UTC
 Tried 10.0.5 now also have this issue, so all 10.x.x are affected... not sure how far backwards i can go with kabini, but also maybe it is not regression :).
Comment 6 Michel Dänzer 2014-04-23 09:27:42 UTC
Is there anything interesting in the game's terminal output, e.g. related to shader compile failures?

If not, can you create an apitrace demonstrating the problem?
Comment 7 smoki 2014-04-23 13:57:51 UTC
 I think i see nothing in console... Tried to make short traces of both cases :).

 https://dl.dropboxusercontent.com/u/74553632/traces.zip
Comment 8 smoki 2014-04-23 16:11:09 UTC
 Don't have a time for this right now, but better this with turn on/off headlights i think clearly show behavior, hope it is reproducible :).

 https://dl.dropboxusercontent.com/u/74553632/pttm_trace2.7z
Comment 9 Rafael Castillo 2014-05-16 23:01:37 UTC
confirmed on Cape Verde 7770 running the traces

llvm 3.5svn at may 16, mesa git, xorg-1.16
Comment 10 Michel Dänzer 2014-05-17 02:12:06 UTC
smoki, your comments on Phoronix don't make much sense I'm afraid.

First of all, there's no such thing as no vertex or pixel shader for a Gallium driver. The state tracker always provides both shaders to the driver, even if they don't do anything but pass through values.

I don't think there's anything particularly special about this bug; someone will just have to track down and fix it. Your apitraces will be useful for that, thanks.
Comment 11 smoki 2014-05-17 12:06:40 UTC
 Maybe i need to explain that :). What i am talking there is that PTTM game supports different reder paths: GL1X, ARB, NV1X, NV2X, R2XX and ARB2.
When you started that game it query for extensions, select the best but in settings also let you choose some different if available. Of course  NV1X, NV2X and R2XX paths are not supported by radeonsi and thase are not listed.  So i have there so called ARB2 by default which shows a bug, so i tried ARB and GL1X these also shows a bug.

 Now i tried next game in the series 18 Wheels of Steel American Long Haul, that supports these and some more NV3X and NV4X, but that is for nvidia so not listed.
That game shows the same bug with ARB, ARB1 paths but now works with ARB2 :) - that is the only render path which does not have this bug. And why, in PTTM ARB2 query only for fragment program extension, but in ALH it query for both vertex and fragment program extension.

 So what i am saying there is, bug is not there when game use both, but bug is there in any different situation when both are not used :).
Comment 12 smoki 2014-05-17 12:27:07 UTC
 And of course then i came to the that AirStrike3D game case, simple OpenGL 1.2 game i think which does not use any of these but show the same bug :). That game can i think can work without extensions at all, but it enable some like multitexture, vertex arrays, texture env add and texture combine when available.
Comment 13 smoki 2014-05-17 13:10:18 UTC
Created attachment 99217 [details]
STK-black


 Nah, i found now another blackiness in another game case now when FBO is not used :D. Maybe this is problem only with some formats used, i think i will checkeout this :).
Comment 14 smoki 2014-05-17 13:20:00 UTC
 It is XRGB, MESA_FORMAT_B8G8R8X8_UNORM but need to checked it out in real situations... a think intel disable support for this "memory saver" format in screen, but radeon in classic and gallium leave it enabled :). Does that format need to be supported anymore?
Comment 15 smoki 2014-05-17 14:15:26 UTC
 Not sure how to not effectively not expose that format for radeonsi:

http://lists.freedesktop.org/archives/mesa-dev/2013-January/033029.html

 In dri2.c, dri_screen.c, dri_drawable.c... :) ?
Comment 16 smoki 2014-05-17 14:52:47 UTC
 Disabling XRGB it in following files fixes an issue in supertuxkart non FBO case :)
 
src/gallium/state_trackers/dri/common/dri_screen.c
src/mesa/drivers/dri/radeon/radeon_screen.c

 But this is another problem, unsolvable by this :(.
Comment 17 smoki 2014-05-17 15:38:30 UTC
 Actually AirStrike3D is also fixed by not exposing XRGB :). I didn't mention that game also needs to be running under MESA_EXTENSION_MAX_YEAR=2003 env ;).
Comment 18 smoki 2014-05-18 15:27:16 UTC
 So i disabled it like in this commit, array size undefined and remove it:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=75b7e1df139676f2456fea4d3a57cf0044d8409e

 For PTTM and ATH games that does not help, but looks very similar to be format issue... it just needs alpha there but not got that :).
Comment 19 Michel Dänzer 2014-05-19 06:09:02 UTC
(In reply to comment #14)
> It is XRGB, MESA_FORMAT_B8G8R8X8_UNORM but need to checked it out in real
> situations... a think intel disable support for this "memory saver" format
> in screen, but radeon in classic and gallium leave it enabled :).

MESA_FORMAT_B8G8R8X8_UNORM has nothing to do with memory saving (it's the same as MESA_FORMAT_B8G8R8A8_UNORM as far as memory layout is concerned), it just means that the contents of the 'alpha' channel in memory are ignored.


> Does that format need to be supported anymore?

Yes. We need to find out where and how this format ends up being used incorrectly. Note that this might be in Wine / in the apps themselves.


Anyway, your comments #17 and #18 mean that the PTTM/ATH and AirStrike3D issues are probably not one and the same bug and need to be tracked separately. The AirStrike3D and SuperTuxKart issues might be related, but it's better to assume they're separate as well for now, to avoid cluttering up a single report with unrelated issues.
Comment 20 smoki 2014-05-20 00:31:35 UTC
Created attachment 99363 [details]
Trine 2 - radeon


 One more example of those blackiness, with Trine 2 game. Game is also partially black like WoS games, so maybe it is the same issue :).
Comment 21 smoki 2014-05-20 00:32:31 UTC
Created attachment 99364 [details]
Trine 2 - fglrx
Comment 22 Alex Deucher 2014-05-20 13:30:31 UTC
(In reply to comment #20)
> Created attachment 99363 [details]
> Trine 2 - radeon
> 
> 
>  One more example of those blackiness, with Trine 2 game. Game is also
> partially black like WoS games, so maybe it is the same issue :).

You are probably seeing bug 66067 for trine 2.
Comment 23 smoki 2014-05-20 17:08:30 UTC
(In reply to comment #22)
> You are probably seeing bug 66067 for trine 2.

 Yes i saw that bug, sound like unsupportabile from Roland's comment :). I also saw Grigory's hack, but that is different r600_shader does not use llvm backend... and this is about SI, so thing may be different and don't know how i can hack si_shader similar? So most probobly that is it for Trine 2, but maybe that hack will also help in this case, etc...

 https://bugs.freedesktop.org/attachment.cgi?id=86032

 So if someone know how to hack that like for r600 but for SI to approve it is the same, i will be glad to try that :).
Comment 24 smoki 2014-05-20 18:58:23 UTC
Created attachment 99435 [details]
Unigine Sanctuary - radeon


 Similar blackiness for today with Unigine Sanctuary.
Comment 25 smoki 2014-05-20 18:59:58 UTC
Created attachment 99436 [details]
Unigine Sanctuary - fglrx


 In comparation with fglrx, radeon have blackiness with some lighting invilved :).
Comment 26 Michel Dänzer 2014-05-21 14:58:14 UTC
(In reply to comment #25)
>  In comparation with fglrx, radeon have blackiness with some lighting
> invilved :).

Does it look different from radeonsi with any other Mesa driver? E.g. Unigine might use the GL_ARB_shadow_ambient extension, which is supported by fglrx but not by Mesa.


Please realize that 'black pixels' is not specific enough to characterize a single bug. This report is getting unmanageable, please track issues in separate apps in separate reports and stop mixing in more here.
Comment 27 smoki 2014-05-21 17:52:45 UTC
(In reply to comment #26)
> Does it look different from radeonsi with any other Mesa driver? E.g.
> Unigine might use the GL_ARB_shadow_ambient extension, which is supported by
> fglrx but not by Mesa.

 Swrast is OK, behave much like fglrx :). But radeonsi's shadows looks broken in various ways, they are darker, missing and missplaced... i will open separete bug for the issue today.
Comment 28 Michel Dänzer 2014-07-15 07:44:30 UTC
This report has become an intractable mess. One report per app/problem, please.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.