iXit / wine-nine-standalone

Build Gallium Nine support on top of an existing WINE installation
GNU Lesser General Public License v2.1
272 stars 23 forks source link

Skyrim: triple buffering doesn't seem to be working correctly #38

Closed aufkrawall closed 4 years ago

aufkrawall commented 5 years ago

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.

axeldavy commented 5 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 ?

aufkrawall commented 5 years ago

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=2doesn't seeem to have an effect, the frametime still constantly switches between full and half refreshrate: Screenshot_20190522_204009 This is definitely not the case on Windows. :)

axeldavy commented 5 years ago

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.

aufkrawall commented 5 years ago

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: Screenshot_20190522_211236 Screenshot_20190522_211447

axeldavy commented 5 years ago

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.

aufkrawall commented 5 years ago

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): Screenshot_20190526_191730

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.

aufkrawall commented 5 years ago

Ok, the game seems to really need throttle_value=3, with =2 there is still weird frametime inconsistency when fps being below refresh rate: Screenshot_20190526_200040 Screenshot_20190526_200255

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.

aufkrawall commented 5 years ago

Was able to capture the corruption: mpv-shot0025

Edit: AMD_DEBUG=nodma seems to fix/workaround it. Yey! :)

aufkrawall commented 5 years ago

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?

aufkrawall commented 5 years ago

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.

axeldavy commented 5 years ago

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.

aufkrawall commented 5 years ago

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.

aufkrawall commented 4 years ago

@axeldavy Since this mesa commit, just specifying thread_submit=trueis 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?

axeldavy commented 4 years ago

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.

aufkrawall commented 4 years ago

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.