Skyrim: triple buffering doesn't seem to be working correctly about wine-nine-standalone

[axeldavy]

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.

[axeldavy]

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]

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:

This is definitely not the case on Windows. :)

[axeldavy]

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]

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:

[axeldavy]

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]

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.

[aufkrawall]

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.

[aufkrawall]

Was able to capture the corruption:

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

[aufkrawall]

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]

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.

[aufkrawall]

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]

@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]

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]

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.