Closed aufkrawall closed 4 years ago
We implement true d3d behaviour by default, which is no triple buffering. It is not the ogl behaviour, and thus what wined3d get.
However you can activate it with tearfree_discard=true: vblank_mode=0 tearfree_discard=true gives triple buffering
That said I think when you say 'triple buffering', you have something else in mind. Some users reported a regression due a recent mesa change. Does throttle_value=2 fixes your issue with vsync on ?
Thanks for your reply. vblank_mode=0 tearfree_discard=true
doesn't limit fps to the refreshrate, so there is noticeable stuttering all the time.
throttle_value=2
doesn't seeem to have an effect, the frametime still constantly switches between full and half refreshrate:
This is definitely not the case on Windows. :)
Well possibly you have another issue as well. Can you try the previous parametersn but in addition use thread_submit=true ?
Basically the buffers sent to the display with this parameter have finished completly rendering. It can add a frame lag if the GPU renders at the same refresh rate the display, but it prevents frame skipping.
You were apparently absolutely right with your idea that something else must be wrong, as there is no problem when running it inside a Plasma Wayland session via xwayland instead of native xserver session:
I can reproduce the issue thread_submit=true throttle_value=2 fixes the issue here (you can try thread_submit=true throttle_value=3 if that is not enough). thread_submit alone or high throttle_value weren't enough.
I can confirm that the values you provided do the trick, performance in CPU limit also is increased (that's inside a native xorg session again now):
Totally different topic, but I wanna mention it nevertheless: Now if there weren't that terrible bug in the AMD OpenGL/Gallium driver: https://bugs.freedesktop.org/show_bug.cgi?id=110635 It ruins visuals for me in a lot of games played with OpenGL / Gallium Nine on Polaris, applies also to Skyrim. :( There's random white flashing, and it can happen quite a lot in a row. If anybody has noticed this issue as well and could shed some light into it to help fixing, I'd be really grateful. Vulkan applications are 100% free of artifacts and there are also reports of other users, e.g. concerning the same corruption in Counter-Strike: Global Offensive, so it can't be a hardware issue.
Ok, the game seems to really need throttle_value=3, with =2 there is still weird frametime inconsistency when fps being below refresh rate:
It's not the exact same scene, as the CPU performance seems to worsen after playing the game for some time (what a great game engine this is :p ). I suppose this also applies to other GameBryo titles such as Fallout 3 etc.
Was able to capture the corruption:
Edit: AMD_DEBUG=nodma seems to fix/workaround it. Yey! :)
Oblivion is affected as well by the vsync issue and profits by the commands you provided. I think it's likely that all other GameBryo DX9 games (Fallout 3/NV) are affected as well. Or is this a general issue with any game and vsync? My impression is that thread_submit=true throttle_value=3 doesn't have a higher input lag than WineD3D or D9VK, so perhaps it would be a good default setting?
There's unfortunately also another problem shared among Skyrim and Oblivion: Sometimes the games start to stutter with any mouse or keyboard input and thus need to be restarted. The stuttering is also visible in the frametime graph and it's totally smooth without any mouse or keyboard input. This issue seems to be triggered rather randomly, but some effect or temporary performance drop may be faulty.
When thread_submit=true, there is an input lag proportionnal to throttle_value. I need to understand why in your case 3 is better than 2.
For Oblivion, a value of 2 is enough. Perhaps there is a connection to Skyrim being more multithreaded?
Regarding the weird stutter problem that requires a restart of both games: I suspect it might be related to Steam Overlay, which also tries to render some achievements on top, despite it being disabled. I'm running Steam inside Wine now, instead of using Proton, which also maintains Steam Overlay functionality in general. Will report back if the issue reoccurs with it.
@axeldavy Since this mesa commit, just specifying thread_submit=true
is sufficient to achieve proper triple buffering:
https://gitlab.freedesktop.org/mesa/mesa/commit/b012f06d66100272f9bdf3d8f7fd0730d072ceee
I wonder why thread_submit=true
isn't used by default when vsync is used.
@dhewg I hope @axeldavy is well, but is he still around?
Well this is quite mysterious to me why this comming, which affects ogl, would help in your case.
You must be right, it must be related to steam overlay doing some weird rendering stuff.
and I'm well, thanks.
Closing the issue then as it is resolved.
Glad to hear! Regarding the Steam overlay: I assumed it only being responsible for the random weird camera jittering (I suspect this to be still valid). The vsync backbuffer issue in Oblivion/Skyrim also happens without Steam involved at all.
Current status with latest mesa git-master and Gallium Nine is that vsync in both games leads to double buffering: Framerate can get capped to a divisor of the display's refreshrate, e.g. 30fps with 60Hz.
Some games also do this on native Windows/D3D, but I'd say that this usally always is undesired behavior. And in the case of Oblivion/Skyrim, I think the games also run with triple buffering on Windows instead (e.g. ~55fps instead of 30).
So I wonder if enabling thread_submit=true
would only have the advantage of having proper triple buffering, without drawbacks?
With D9VK, the games also run with triple buffering vsync.
As the game is a CPU performance nightmare, there are frequent fps dips below the refreshrate. The game requires vsync (and preferably display refefreshrate of 60Hz) to make its physics work correctly. If triple buffering works correctly (which is the case with wined3d), the fps drops aren't so dramatic.
However, Gallium Nine seems to have a problem here, as the game feels really juddery when such dips occur. You can work around this by forcing
vblank_mode=0
, which makes it behave normally like any other game without vsync. However, this introduces tearing and breaks the game's physics due to unlocked fps. A real fix would be properly working triple buffering (At least I suppose so.).This is with latest -git of everything and an RX 580 inside a DRI3 xorg session.