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 :)
Created attachment 97778 [details] good case
Created attachment 97780 [details] bad case
Created attachment 97781 [details] good case (swrast)
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 ;).
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 :).
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?
I think i see nothing in console... Tried to make short traces of both cases :). https://dl.dropboxusercontent.com/u/74553632/traces.zip
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
confirmed on Cape Verde 7770 running the traces llvm 3.5svn at may 16, mesa git, xorg-1.16
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.
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 :).
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.
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 :).
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?
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... :) ?
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 :(.
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 ;).
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 :).
(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.
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 :).
Created attachment 99364 [details] Trine 2 - fglrx
(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.
(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 :).
Created attachment 99435 [details] Unigine Sanctuary - radeon Similar blackiness for today with Unigine Sanctuary.
Created attachment 99436 [details] Unigine Sanctuary - fglrx In comparation with fglrx, radeon have blackiness with some lighting invilved :).
(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.
(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.
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.