Update backend and rework rendering pipeline

[osy]

• Update QEMU to v7.1.0
• Workaround https://gitlab.com/qemu-project/qemu/-/issues/1391
• Update ANGLE and virglrenderer
• Fix deadlock caused by gstosxaudio
• Fix crash from GL_DRAW_COOKIE_INVALID error
• Fix memory leak with ANGLE Metal backend
• Workaround https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20380 and https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1006
• Disable GL error check in virglrenderer to prevent lockups due to unsupported features
• Rework CSRenderer to sync up better with GL texture from the QEMU process. This will make graphics feel more smooth.

Fixes #3053
Fixes #3060
Fixes #3519
Fixes #4449
Fixes #4722

[osy]

Validation testing by running SuperTuxKart for 2 hours without crashing:

• Intel Mac with OpenGL ANGLE
• Intel Mac with Metal ANGLE
• M1 Mac with OpenGL ANGLE
• M1 Mac with Metal ANGLE
• iPhone (emulation) with Metal ANGLE
• M1 iPad Pro (emulation) with Metal ANGLE
• M1 iPad Pro (virtualization) with Metal ANGLE

[ktprograms]

Is there OpenGL 3.2 or whatever is needed by SuperTuxKart available? Or is it just running with broken rendering?

[osy]

It’s definitely not fully rendering (like I don’t think shadow maps are working). But I’m more interested in not crashing the VM then all 3D graphics are working.

[osy]

iPad ran overnight without crashing or going out of memory :)

[SugarRayLua]

@osy & @ktprograms, I was able to get SuperTuxKart also working on my M1 iPad Pro.
SuperTuxKart warned that OpenGL 3.x was not available and may have decreased performance but seemed to allow running on OpenGL 2.x and did not crash.

However, I'd still be concerned there might be a memory leak with the metal backend. I tried to run glxgears using the same setup, and it would run for a second or two and then UTM would crash. While glxgears did run, it ran very smoothly. Perhaps glxgears is using some OpenGL calls that SuperTuxKart is not. Yet, if UTM crashes with GL-acceleration on glxgears, I'd be concerned that it might crash on some other basic GL-accelerated programs not yet tested.

Can anyone else confirm whether they can run glxgears on UTM without it crashing? I apologize but for some reason my UTM won't produce a debug file after the crash for me to export for review.

The system I tested it on was:
M1 iPad Pro
UTM v.4.1.3 pre-release
ARM64
3G ram allocated to VM
Debian 11 LDXE from the UTM gallery
Display: virtio-gpu-gl-pci and virtio-ramfb-gl both similarly crash

(Of note, I also tested glxgears on two other debian-based distributions x86-64 distros [Sparkylinux & antiX], and they similarly crashed with glxgears)

glxgears is available in Debian 11 by the mesa-utils pkg in the Debian repository

Fyi