VOGONS


QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

Topic actions

Reply 221 of 225, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

The latest QEMU 4.2.0 has an updated audio engine with new APIs. All the existing audio backends have to be ported for the new audio APIs. The only common backend between Windows and Linux is SDL audio, but it only works for SDL1.2 and has been broken for SDL2 due to the preference of float32 audio format default in SDL2. QEMU currently does not support any kind of AUDIO_F32 flavors and failed with unknown audio format for QEMU_AUDIO_DRV=sdl.

The Windows native DirectSound backend was broken since the new audio API. Again sigh..., it just proved that Windows build is largely ignored by the developers community. QEMU version >= 4.0.0 dropped SDL1.2, leaving dsound the only usable backend for Windows. And then, dsound was broken after the new rewrite of audio APIs, so leaving audio on Windows totally busted.

Attach the patch to fix both issues. The SDL patch applies for any QEMU versions that linked against SDL2, but I tested only QEMU version >= 4.0.0. The dsound patch fixes QEMU 4.2.0.

Update: QEMU dsoundaudio fix from upstream.

Attachments

Last edited by kjliew on 2020-02-07, 01:08. Edited 1 time in total.

Reply 222 of 225, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie

Thanks, but if someone is not friendly with build such stuff, some text diff files are.. less say unless in good way of thing about it.

Why these changes arent committed to master or why is not possible just to provide whole Windows binaries for download? I think that such things really making Qemu more obscure than that needs to be in comparision with more user friendly things like Vmware, Virtualbox, even Hyper-V.

Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.

Reply 225 of 225, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

QEMU threaded its internal workloads very much. There is one UI main process, each CPU has its own thread, block I/O on its own thread, each screen has its own rendering thread and audio also on its own thread. So at minimum, there will be 1 process and 4 threads running. I think it depends on the OS to spread the workload to different cores. Glide pass-through runs on the main process which runs the host wrappers. Games on Glide API are known to be CPU light and GPU heavy, so typically we will see one heavy-loaded CPU (UI main process running host wrapper), one half-loaded CPU (40%~60% running the CPU assuming the game is also somewhere CPU loaded, such as Unreal fly-by at 1024x768) and several lightly-loaded CPUs. QEMU screen rendering threads simply discard their screen updates when Glide pass-through is active.