The Elden Ring stutter work was unrelated to this effort, it was work in vkd3d-proton by Hans-Kristian Arntzen as part of our open-source graphics effort.
I would keep in mind that the results reported there are likely quite a bit lower (in terms of CPU-side performance) than what you could achieve in practice, because it's running all of x86 Steam+Proton in the emulator. In a pre-configured environment (like SteamOS for ARM), the Steam client and Proton itself would be native ARM code, and emulation would stop at the win32 API boundary (or at certain critical libraries' APIs if you're using Linux apps).
The L3 finding on Linux is likely caused by the C3 entry cache flush, which goes away in our upcoming 6.1 kernel. It doesn't affect most game workloads but can be a real performance problem in some specific cases.
For those that don't know (like me, three minutes ago) gamescope [1] is a Wayland compositor custom-written for games (and, I believe, what the Steam Deck uses). it's open source, and under the "BSD 2-clause" license.
It seems to be a conversation where Deepak Sharma talks about needing to resubmit a patch (and a follow up patch), rather than be the submitted patches themselves.
Cool. Can I ask why does valve/steamdeck use Gamescope and not Wayland?
To my very limited understanding they both target to do more or less the same thing, and I think we have enough fragmentation in the Linux ecosystem as it is, so to my uninitiated brain it would have seemed logical to put al that development effort in improving Wayland for the steamdeck instead of building another compositor.
Wayland is just a protocol. GNOME and KDE both use their own Wayland compositors for example. Gamescope as a gaming focused Wayland compositor probably has more emphasis on things like latency than other compositors.
reply