Bug 53972 - Black Mirror III: too dark
Black Mirror III: too dark
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965
unspecified
Other All
: medium normal
Assigned To: Ian Romanick
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-23 15:57 UTC by Alexander E. Patrakov
Modified: 2012-09-30 14:24 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Correct rendering (865.79 KB, image/png)
2012-08-23 15:58 UTC, Alexander E. Patrakov
Details
Incorrect rendering of approximately the same scene (684.29 KB, image/png)
2012-08-23 16:08 UTC, Alexander E. Patrakov
Details
Patch to fix the problem (1.87 KB, patch)
2012-09-19 01:55 UTC, Matt Turner
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander E. Patrakov 2012-08-23 15:57:28 UTC
This is a regression between mesa-7.10.3 and mesa-7.11_rc1-r1 (-r1 means gentoo-specific revision 1, no longer available from Gentoo). Originally reported as https://bugs.gentoo.org/show_bug.cgi?id=375487, and still present as of 8.0.3.

To reproduce: install BlackMirror III in wine, wait over the intro, look at the inspector room. It is too dark. I will attach screenshots demonstrating this.

I have also recorded API traces using apitrace (they will be automatically deleted in 10 days, please rehost somewhere):

From 7.10.3: http://zalil.ru/33701592

From 8.0.3: http://zalil.ru/33701575

Note that the trace recorded from 7.10.3 replays correctly on 8.0.3, so this may be a game bug (i.e. it genuinely draws different things with different mesa versions). In this case, it would be nice to hear about possible workarounds (such as disabling certain extensions) or whatever I need to tell wine guys so that they actually look at the bug.

The video card is:

00:02.0 VGA compatible controller: Intel Corporation 82G965 Integrated Graphics Controller (rev 02)
00:02.0 0300: 8086:29a2 (rev 02)
Comment 1 Alexander E. Patrakov 2012-08-23 15:58:24 UTC
Created attachment 66021 [details]
Correct rendering
Comment 2 Alexander E. Patrakov 2012-08-23 16:08:46 UTC
Created attachment 66022 [details]
Incorrect rendering of approximately the same scene
Comment 3 Matt Turner 2012-08-23 16:41:21 UTC
(In reply to comment #0)
> I have also recorded API traces using apitrace (they will be automatically
> deleted in 10 days, please rehost somewhere):
> 
> From 7.10.3: http://zalil.ru/33701592
> 
> From 8.0.3: http://zalil.ru/33701575

I can't access these at work. The firewall claims it's a malicious site. :)
Comment 4 Alexander E. Patrakov 2012-08-23 16:58:58 UTC
So which file-sharing site (i.e. rapidshare clone) can you recommend that isn't blocked? The files are slightly shorter than 30 MB.
Comment 5 Matt Turner 2012-09-10 16:45:52 UTC
(In reply to comment #4)
> So which file-sharing site (i.e. rapidshare clone) can you recommend that isn't
> blocked? The files are slightly shorter than 30 MB.

I think rapidshare should be okay. (Sorry for the delay)
Comment 6 Matt Turner 2012-09-13 04:02:36 UTC
(In reply to comment #4)
> So which file-sharing site (i.e. rapidshare clone) can you recommend that isn't
> blocked? The files are slightly shorter than 30 MB.

Can you reupload the API trace files?
Comment 7 Alexander E. Patrakov 2012-09-13 07:39:07 UTC
Hm. Rapidshare requires registration, and I am too lazy for that. I hope that at least one of wikisend.com and depositfiles.com is not blocked for you.

http://wikisend.com/download/615352/wine-preloader-repacked.7.10.3.trace.xz
http://wikisend.com/download/417412/wine-preloader-repacked.8.0.3.trace.xz

http://depositfiles.com/files/mnu6fw1ut (that's from 7.10.3)
http://depositfiles.com/files/0zj53vnm5 (that's from 8.0.3)

TTL: 7 days on wikisend, 30 days on depositfiles.
Comment 8 Matt Turner 2012-09-18 22:02:56 UTC
Thanks for reposting the traces.

I've confirmed the bug on by replaying the 8.0.3 trace on Mesa 8.0.3 on gen4 and gen6. Replaying the 7.10.3 trace on 8.0.3 does not show any problem, which is interesting. Playing both traces on Mesa master shows no problems, so it appears the bug has been fixed.

It is not fixed on the 8.0 branch though. I'm not sure how much we should bother with that, since 9.0 will be released very soon. Is getting this fixed on 8.0 important for you?

As an interesting side-note: when replaying on master the trace captured on 7.10.3 I see a lot of

> glPixelStorei(pname = GL_UNPACK_CLIENT_STORAGE_APPLE, param = 0)
> 56044: warning: glGetError(glPixelStorei) = GL_INVALID_ENUM

The apple client storage extension was removed between 7.10 and 8.0. See http://cgit.freedesktop.org/mesa/mesa/commit/?id=9e9a76eea17bc92c8ac74323c99e10b9480ee583

So I guess there was (is) at least one use of it.
Comment 9 Matt Turner 2012-09-19 01:55:45 UTC
Created attachment 67360 [details] [review]
Patch to fix the problem

Okay, so I bisected it and found the commit that fixes the problem (19bd5936af7278c0cce0728e8d6dec1a951eaf58)

Attached is the cherry-picked fix that applies to the 8.0 branch. Let me know if it works for you.

It's already in a branch waiting for Ian to add it to 8.0 before the 8.0.5 release. So I guess we don't really have to do anything else.
Comment 10 Alexander E. Patrakov 2012-09-30 14:24:34 UTC
I can confirm that a git snapshot currently used in gentoo no longer has this problem. Thus, closing as fixed.