Bug 37150 - sRGB textures are too bright in Starcraft 2
sRGB textures are too bright in Starcraft 2
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Mesa core
git
Other All
: medium normal
Assigned To: mesa-dev
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-12 14:06 UTC by Pavel Ondračka
Modified: 2011-05-24 13:23 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Ondračka 2011-05-12 14:06:59 UTC
When Starcraft 2 is started menus have normal color, however when I start
a mission and then exit back to the menus, they are overbright. Not the whole menu is too bright, background is fine, only the user interface is too bright. The same is true for ingame controls panels, on the first load they are ok, when starting second game, they are too bright and in each subsequent game this is getting worse.

Setting MESA_EXTENSION_OVERRIDE="-GL_EXT_texture_sRGB_decode" fixes this.

More info and screenshots in this Wine bug: http://bugs.winehq.org/show_bug.cgi?id=26752
I had opened bug against Wine since this was introduced by Wine update, but the offending commit was "wined3d: Use EXT_texture_sRGB_decode to avoid sRGB texture duplication" and Henri Verbeet indicated this could be as well a mesa bug. Btw NVIDIA driver is fine.

Setting component to mesa core because llvmpipe is affected as well.
Comment 1 Pavel Ondračka 2011-05-12 14:16:44 UTC
I forgot to mention:
OpenGL renderer string: Gallium 0.4 on ATI RV530
OpenGL version string: 2.1 Mesa 7.11-devel (git-32a95cb)
Comment 2 Sven Arvidsson 2011-05-13 04:08:26 UTC
I'm having the same problem with STALKER: Clear Sky in Wine. Every time the settings menu is opened, it get's a little bit brighter.
Comment 3 Henri Verbeet 2011-05-13 04:46:58 UTC
FWIW, my impression is that there's a copy / transfer somewhere that applies color space conversion while it shouldn't, similar to the issue fixed by commit ab21147c899ba1506df38438b6750d3dc5eaabdf. I don't think StarCraft 2 for example uses sRGB much if at all, but when EXT_texture_sRGB_decode is present Wine creates textures using sRGB formats and sets TEXTURE_SRGB_DECODE_EXT to SKIP_DECODE_EXT.
Comment 4 Bryan Cain 2011-05-13 05:22:32 UTC
I'm having the same problem with Portal in Wine.  In the middle of gameplay, the screen quickly gets much brighter, like the gamma has been ramped up.  It eventually goes back to normal.  I don't remember whether it goes back to normal spontaneously (like the appearance of the issue) or only after dying and respawning.

Since I doubt it uses sRGB textures in the game (it is running with Direct3D 8), Henri Verbeet's impression seems correct to me.
Comment 5 Tobias Jakobi 2011-05-13 11:30:00 UTC
Adding FEAR to the list of affected games. Loading screen gets brighter while loading process advances. This carries over to the menu later.
Comment 6 David Mills 2011-05-13 11:50:10 UTC
I don't know if this is the same bug, but in SC2 the gamma ramped up during the loading screen, each time getting brighter and brighter. The only thing is that I also observed this on another machine running a NVidia card using the blob. 

That may indicate a wine bug rather than a mesa one.
Comment 7 Jaime Rave 2011-05-13 12:34:39 UTC
This is a dup of bug 35373 or at least is related to it.
Comment 8 Christoph Bumiller 2011-05-13 16:40:53 UTC
Check piglit's fbo-srgb-blit, it makes the state tracker order a resource_copy_region between UNORM and SRGB which causes unwanted conversion if you do a normal oblivious 3D engine copy in your driver. The function isn't supposed to convert anything.
Comment 9 Marek Olšák 2011-05-13 17:07:09 UTC
(In reply to comment #8)
> Check piglit's fbo-srgb-blit, it makes the state tracker order a
> resource_copy_region between UNORM and SRGB which causes unwanted conversion if
> you do a normal oblivious 3D engine copy in your driver. The function isn't
> supposed to convert anything.

The u_blitter module linearizes the formats when creating sampler views and surfaces. fbo-srgb-blit passes.

There is an unwanted conversion somewhere, but it's certainly not in resource_copy_region.

The fact David Mills observed the same issue on the NVIDIA blob suggests this might not be a bug in Mesa.
Comment 10 Bryan Cain 2011-05-13 19:30:58 UTC
(In reply to comment #8)
> Check piglit's fbo-srgb-blit, it makes the state tracker order a
> resource_copy_region between UNORM and SRGB which causes unwanted conversion if
> you do a normal oblivious 3D engine copy in your driver. The function isn't
> supposed to convert anything.

This isn't just a Radeon-specific issue.  It's happening to me in Portal using the nv50 driver.
Comment 11 Henri Verbeet 2011-05-13 20:55:57 UTC
(In reply to comment #9)
> The fact David Mills observed the same issue on the NVIDIA blob suggests this
> might not be a bug in Mesa.
Wine having bugs isn't unheard of, but I'm not sure the NVIDIA blob actually supports EXT_texture_sRGB_decode. Last time I checked it wasn't in 270.x, though perhaps they added it in some of the more recent versions. Either way, it just needs some careful debugging, haven't gotten around to it myself.

Wrt. fbo-srgb-blit, I added that together with ab21147c899ba1506df38438b6750d3dc5eaabdf. In principle it should currently pass for Gallium drivers, and used to fail on at least (classic) i965. I'm not sure if the situation for i965 changed, but that's what bug 35373 is about. It's not related to this bug, other than that it might be a similar issue in a different location.
Comment 12 Pavel Ondračka 2011-05-14 12:17:58 UTC
(In reply to comment #6)
> I don't know if this is the same bug, but in SC2 the gamma ramped up during the
> loading screen, each time getting brighter and brighter. The only thing is that
> I also observed this on another machine running a NVidia card using the blob. 
> 
> That may indicate a wine bug rather than a mesa one.

I don't know if this bug is the same, my overall gamma levels are normal just some specific textures are too bright.
Comment 13 Benjamin Bellec 2011-05-14 19:35:48 UTC
I must add that I have a similar behavior in some (reproducible) cases in Civilization IV (hence a Wined game) BUT I have ALSO over-brightened scenes in etqw/r600g:
I can only play ETQW with r600g since 2.6.39-rc kernel (due to s3tc kernel-in support), and as far as i know, 3D-model character (in the limbo menu) are over-brightened. All the game is fine, but the 3D modelized character in the "limbo menu" are over-bright.
Comment 14 David Mills 2011-05-15 00:24:21 UTC
Just for clarification: the bug I mentioned only affected the menus in SC2, in-game rendering was fine (going back to the menu or opening the in-game menu showed the bug again). This seems to support the texture theory over the gamma one if I'm not mistaken.
Comment 15 Sven Arvidsson 2011-05-21 16:37:56 UTC
There was a patch posted to the mailing list which seems to solve this. It's at least working for the game I mentioned previously.

http://lists.freedesktop.org/archives/mesa-dev/2011-May/007757.html
Comment 16 Benjamin Bellec 2011-05-22 13:13:20 UTC
(In reply to comment #15)
> There was a patch posted to the mailing list which seems to solve this. It's at
> least working for the game I mentioned previously.
> 
> http://lists.freedesktop.org/archives/mesa-dev/2011-May/007757.html

This patch fix Wine/CivilizationIV too.
But not ETQW (native) so perhaps it's another issue for this game.
Comment 17 Sven Arvidsson 2011-05-22 13:18:20 UTC
(In reply to comment #16)
> But not ETQW (native) so perhaps it's another issue for this game.

If it's the same problem setting MESA_EXTENSION_OVERRIDE="-GL_EXT_texture_sRGB_decode" should get rid of it.

You could also compare with another driver like llvmpipe (if it's possible to run ETQW with this) if it is rendering correctly it's probably not the same problem.
Comment 18 Pavel Ondračka 2011-05-22 13:50:15 UTC
(In reply to comment #15)
> There was a patch posted to the mailing list which seems to solve this. It's at
> least working for the game I mentioned previously.
> 
> http://lists.freedesktop.org/archives/mesa-dev/2011-May/007757.html

This patch also fix Starcraft 2.
Comment 19 Benjamin Bellec 2011-05-23 12:42:50 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > But not ETQW (native) so perhaps it's another issue for this game.
> 
> If it's the same problem setting
> MESA_EXTENSION_OVERRIDE="-GL_EXT_texture_sRGB_decode" should get rid of it.

MESA_EXTENSION_OVERRIDE="-GL_EXT_texture_sRGB_decode" doesn't solve the issue in ETQW.

> You could also compare with another driver like llvmpipe (if it's possible to
> run ETQW with this) if it is rendering correctly it's probably not the same
> problem.
It's the same with gallium-swrast. Issue persists.
Curiously, running ETQW with gallium-swrast is totally playable, almost like r600g.
Comment 20 Brian Paul 2011-05-24 08:08:14 UTC
Can you guys retest with Mesa commit d3b6e8a2b8e3581e07a6dd7277d4d4c6c0407760?
Comment 21 Benjamin Bellec 2011-05-24 10:56:21 UTC
(In reply to comment #20)
> Can you guys retest with Mesa commit d3b6e8a2b8e3581e07a6dd7277d4d4c6c0407760?

It's the same for me:
- fix Wine/CivilizationIV
- doesn't fix ETQW
Comment 22 Sven Arvidsson 2011-05-24 12:12:32 UTC
Yep, it's working fine-
Comment 23 Benjamin Bellec 2011-05-24 13:11:43 UTC
(In reply to comment #19)
> Curiously, running ETQW with gallium-swrast is totally playable, almost like
> r600g.

Forget that.
Comment 24 Pavel Ondračka 2011-05-24 13:23:58 UTC
(In reply to comment #20)
> Can you guys retest with Mesa commit d3b6e8a2b8e3581e07a6dd7277d4d4c6c0407760?

Fixed, thanks.