vfio VS gamescope

If you love wasting time you could give my script a shot as well from a terminal with your gpu as the -pci argument, but you'll also want to give it your USB controllers too.

In my script I have -name main,debug-threads=on in my qemu command which helps me find which child thread is the iothread. I do my pinning using the same debug thread name discovery method.

Yeah my script is public and can be found here. I've thought about making an actual link post here a few times in the past but I guess the time to do so never really came up.

These boot arguments allow me to give my VM cores 3,11 to my guest while my host continues to operate (and handle any IOThreads I may have running for the guest) on the remaining cores 0(thread0,12), core1(thread1,13) and core3 (thread2,14). Personally, I handle my pinning dynamically with a bash script I wrote and still today find myself adding features and making improvements to. It can be found here if you want to give it a shot for your use case.

How does this compare to /u/ipaqmaster's script which accepts one-liners for single or dual and you're set?

You'll get further posting here by detailing what exactly is going wrong when you try and any configuration and scripts you tried to do it with. There are also scripts which try to be the everyman and do it all for you such as this vfio bash script written by one of the members here.

You may wish to try my vfio script which handles all of that automatically. Could be worth a try.

I've missed no opportunity to plug it lately, but the slew of people using hardcoded scripts copy-pasted from some guide or youtube video has never felt right to me. I made my own dynamic script which handles most vfio problems on the fly rather than hardcoding start.sh/stop.sh scripts per configuration. It could be worth checking out given I made it for Archlinux (my desktop) and you seem to be running that too.

I use this script to help start the qemu VM (there were no recent changes to the script) (I can paste the full qemu_system_x86_64 command if that would help) https://github.com/ipaqmaster/vfio

Well, if you'd be willing to give it a test drive just for fun I made and use this for my daily VFIO ease of access if you'd want to give it a try.

I think your information is quite outdated. The HWC overlay planes are heavily used, you can see this trivially just doing a 'dumpsys SurfaceFlinger' or grabbing a systrace/perfetto trace. When it falls back to GPU composition it's very obvious as there's a significant hit to latency and more GPU contention.

The overlay capabilities of the modern Snapdragons are also quite absurd. They support like upwards of a dozen overlays now and even have FP16 extended sRGB support. Some HWCs (like the one in the steam deck) even have per plane 3D LUTs for HDR tone mapping (ex https://github.com/ValveSoftware/gamescope/blob/master/src/d... )

The composition is bandwidth heavy of course, but for static scenes there's a cache after the HWC in the form of panel self refresh.

One of the unfortunate things about Wayland is every compositor will have its own quality of implementation affecting things like latency.

With XOrg, especially in the pre-compositing days, you could choose whatever WM you want and it wouldn't have any impact on the rendering performance of X clients. Once the Composite extension was added and everyone started running composited X desktops, that started to change, and the increased latency already started appearing - in an arguably worse architecture than Wayland because there were often three processes involved with lots of IPC per draw: X-Client->X-Server->X-Compositor->X-Server->CRTC. At least in Wayland it's more like Wayland-Client->Wayland-Compositor->CRTC.

If you're unhappy with the rendering latency of your Wayland sessions, it may be worth trying alternative compositors... they likely vary significantly. The Valve/Steam folks have made a minimal one specifically optimized for games/low-latency [0]. I doubt the SteamDeck would be seeing as much success as it is if Wayland were so problematic in this department.

[0]: https://github.com/ValveSoftware/gamescope

Use gamescope.

While streaming from the Deck to another device (phone with Steam Link app or another PC running steam), taking a screenshot on the Deck (hold the steam or ... button, and press R1) crashes the session (https://github.com/ValveSoftware/gamescope/issues/961). This one also impacts Decky Recorder. If you're recording the screen or have replay mode on and take a screenshot, you'll have a crash.

Mangohud (GOverlay), libstrangle, gamescope. Pick your poison.

Hey folks. I've got a 11900H motherboard and use the iGPU and stock Intel graphics drivers that I keep current. Even at baseline (so without overclocking of any kind, with good Corsair memory sticks configured without XMP and regardless of voltage), I would be able to use Windows 11 and the CMD or Terminal programs without issue but after some time they would be corrupt and unreadable. The fix was in Terminal, go into Settings, then Render, and turn on Software Rendering. I hope this helps someone else. FYI the corruption was very much like other Intel UHD graphics samples reported in this link: https://github.com/ValveSoftware/gamescope/issues/356