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.
I forgot to mention: OpenGL renderer string: Gallium 0.4 on ATI RV530 OpenGL version string: 2.1 Mesa 7.11-devel (git-32a95cb)
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.
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.
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.
Adding FEAR to the list of affected games. Loading screen gets brighter while loading process advances. This carries over to the menu later.
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.
This is a dup of bug 35373 or at least is related to it.
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.
(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.
(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.
(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.
(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.
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.
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.
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
(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.
(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.
(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.
(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.
Can you guys retest with Mesa commit d3b6e8a2b8e3581e07a6dd7277d4d4c6c0407760?
(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
Yep, it's working fine-
(In reply to comment #19) > Curiously, running ETQW with gallium-swrast is totally playable, almost like > r600g. Forget that.
(In reply to comment #20) > Can you guys retest with Mesa commit d3b6e8a2b8e3581e07a6dd7277d4d4c6c0407760? Fixed, thanks.
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.