Grand Prix 4 looks too bright with DXVK in full screen mode (windowed looks fine)
An Apitrace would definitely be appreciated. Apitrace records the D3D9 calls, so the DXVK version you use doesn't really matter for that. You can find a brief guide in our Wiki.
Should I provide an apitrace for both, fullscreen mode (showing the issue) and windowed mode (working fine) or just for fullscreen mode?
That would be best.
Also: I don't really follow Elementary OS.
- Does it support HDR in any way?
- Do you have an HDR monitor?
I don't think it supports HDR and I don't have an HDR monitor anyway.
BTW, the issue is noticeable as soon as the game is lauched (intro videos, menues, etc.) not only when going in game (starting a race). Should I run the apitrace until starting a race or it would be enough to run it until reaching the main menu for example?
The gamma ramp validation shenanigans in WineD3D are a bit more complicated than what dxvk does, however the latter should be mostly in line with native. So it's probably best to check and confirm how bright the game looks on Windows and base your expectations on that.
The gamma ramp validation shenanigans in WineD3D are a bit more complicated than what dxvk does, however the latter should be mostly in line with native. So it's probably best to check and confirm how bright the game looks on Windows and base your expectations on that.
Out of curiosity, do you have any idea on why it only happens in full screen mode and not in windowed mode?
I found that a bit surprising to be honest and only discovered by accident while trying to get a screenshot.
Out of curiosity, do you have any idea on why it only happens in full screen mode and not in windowed mode?
That's why I hypothesized this is gamma ramp related in the first place - it will only get applied in fullscreen. Windowed mode will use the desktop environment gamma value.
Got it. Thanks for sharing.
I will install the game on Windows 10 later today and compare how it looks there.
If it looks same as WineD3D I will go ahead and collect the apitrace.
I can confirm that the game looks fine and the same on Windows 10 and WineD3D regardless of the mode (full screen or windowed) and DXVK windowed mode.
Windows 10:
WineD3D:
So it seems the issue is specific to DXVK in full screen mode. I will collect the apitrace and share it.
Please find the apitrace in the link below:
Was the apitrace helpful? Is there any other information needed?
Thanks
All I can say is that replaying the trace (even in full-screen mode, which is subject to things like gamma emulation) looks fine here.
I thought it may be a Mesa issue, so tried with a newer version 25.0.3 instead of 23.2.1 to no avail. I also tried DXVK 2.6.1 just in case.
I took two pictures with my phone in case it helps to show the difference.
DXVK in full screen mode:
DXVK in windowed mode, WineD3D and Windows 10:
I hope the pictures clearly show the difference/problem I'm referring to.
I can try the game on two different PCs just in case, one with a Radeon 6600XT and a Steam Deck.
I have some ideas to at least narrow down the issue, but it's going to be a while before I can start looking into it. Watch this space.
Last night I tested the game on another PC running SteamOS 3 latest version, Mesa 25.0.3 and a Radeon 6600XT GPU but I got the same results as above.
@WinterSnowfall I can test on a Steam Deck (still AMD GPU) and on an older i7-7700 with Intel HD Graphics 630 integrated graphics. Do you think it worth it?
If there is anything you want me to try in the meantime just let me know.
Thanks
After testing the game on the Steam Deck, I have additional information in case it helps.
On the Steam Deck, I found that the game is failing to launch in desktop mode (KDE session -X11-) so I tested it in game mode (Gamescope session -Wayland-) and found that is launching successfully and the "gamma issue" is not happening there. It looks as expected.
So I went back and tested the game again on the PC I mentioned on my previous comment (SteamOS 3 -same image and version as the Steam Deck-, Mesa 25.0.3 and Radeon 6600XT GPU).
The game is launched successfully on both, desktop and game mode, but I discovered that the "gamma issue" is only happening in desktop mode (KDE session -X11-). In game mode (Gamescope session -Wayland-) the game looks as expected.
Makes sense that this issue only affects X11 (KDE session) but not Wayland (Gamescope session)?
Thanks
For the sake of completeness I tested the game on a third PC.
Software information
- OS: Debian (unstable)
- Linux kernel: 6.12.21-amd64
System information
- GPU: Intel Corporation HD Graphics 630
- Driver: Mesa 25.0.3
- Wine version: Wine - Wine-GE-Proton7-43
- DXVK version: 2.6.1
This PC is running KDE 6 (X11 and Wayland sessions) and Gamescope (native).
After testing the three different sessions, the game looks fine when launched in a Gamescope session, but it shows the problem when launched from a desktop session, regardless of using X11 or Wayland.
In summary, the issue can be reproduced with:
- Different GPUs (Radeon 6600XT/6700XT, Steam Deck and Intel HD 630)
- Different Mesa versions (23.2.1 and 25.0.3)
- Different DXVK versions (2.5.2, 2.5.3 and 2.6.1)
- Different desktop environment (KDE 5, KDE 6, Pantheon) and sessions (X11, Wayland)
But it can't be reproduced when launched in a Gamescope session (a.k.a game mode).
Would it help if I share two DXVK logs, one for the game launched in KDE session and one for the game launched in Gamescope session?
Thanks
But it can't be reproduced when launched in a Gamescope session (a.k.a game mode).
Not entirely sure of Gamescope's inner workings, but if it sidesteps exclusive fullscreen and forces borderless fullscreen, then yes, it does make sense.
Would it help if I share two DXVK logs, one for the game launched in KDE session and one for the game launched in Gamescope session?
No, logs won't help much here. The trace is enough, I hope, but haven't (yet) had the time to analyze it. I'll let you know when I get to it, as I will need your help to test things out for sure.
@casasfernando We can scrap my original assumption, the trace does not contain any calls to SetGammaRamp, so it's not that. I'll wait for @Blisto91 to confirm if he can reproduce it or not. At this point I'm not really sure what could be causing it.
Thanks @WinterSnowfall .
Would it help if I collect an apitrace running the game in a gamescope session (game mode) to compare it with the one I already provided?
No, since the trace would be identical. Apitrace does not capture anything related to compositors, just the game's d3d calls.
I mentioned this in a previous comment but in case it went overlooked, the issue is noticeable even in the intro videos and menues, as soon as the game loads and way before going in-game (actual race). Are d3d calls happening so early (before even playing the intro videos)?
Are d3d calls happening so early (before even playing the intro videos)?
Usually, yes. Most games will initialize a d3d device and use it to render the intro videos as well.
I assume this isn't dependent on some mods or settings in the game right? Doing a bit of testing with the game i haven't reproduced so far
I assume this isn't dependent on some mods or settings in the game right? Doing a bit of testing with the game i haven't reproduced so far
You are right. I collected the screenshots right after installing the game from CD in a clean 32-bit prefix.
So the game is using the default/oob settings.
Only DXVK is installed before launching the game for the first time and the issue happens right away, on first run.
Let me know if there is any other information I can provide, or tests you want me to do. I'm really interested into understanding what's going on.
Thanks
What I find really strange is that it seems no one else can reproduce the issue while I can do it every time.
Moreover, the issue is present even on intro videos, no need to go in game or past the main menu.
It's really strange.
May I ask which Wine flavor and version are you using guys? I can try to repro with the same version(s) to at least discard an issue with my Wine version.
I'm using Wine-GE-Proton7-43 because if I try with anything newer than that, the game will not start at all.
I was just using regular upstream Wine 10.6. I can try messing with older or different versions to see if i can get it to show then.
I was just using regular upstream Wine 10.6. I can try messing with older or different versions to see if i can get it to show then.
Tried to repro with regular upstream Wine 10.6 and it's working fine for me as well. Also tried older versions of regular upstream Wine (9.0, 9.22, 10.0) and it works fine with all of them.
The problem seems to be specific to Wine-GE-Proton7-43 (https://github.com/GloriousEggroll/wine-ge-custom/releases/download/GE-Proton7-43/wine-lutris-GE-Proton7-43-x86_64.tar.xz) which seems to be the last "protonified" version of Wine that the game works with. For some reason, the game get's stuck on start up with Valve's Proton8*+, ProtonGE-8*+ and Wine-GE-Proton8*.
Apologies for not testing regular upstream Wine before.
Anyways, @Blisto91 if you are curious and want to try to repro, your best bet is to try Wine-GE-Proton7-43.
Thanks
I was actually not able to get those old Wine-GE versions working with the game, so only tested with newer upstream Wine.
Grand Prix 4 looks too bright when running with DXVK 2.5.3 in full screen mode (the game crashes with 2.6 and opened a separate issue) when compared with windowed mode or WineD3D in full screen mode which in both cases looks as expected.
I can't take a screenshot while in full screen mode but to give you an idea, I found a similar issue here: https://github.com/doitsujin/dxvk/issues/4786
Running with DXVK in windowed mode or with WineD3D in full screen mode the game looks like MSAAx1 example picture on that issue, while with DXVK in full screen mode it looks like the MSAAx2 example.
Let me know if an apitrace is needed in this scenario.
Software information
OS: elementary OS 7.1 (based on Ubuntu 22.04)
Linux kernel: 6.8.0-52-generic
System information
Log files
game_windowed.log
game_fullscreen.log