First post, by kjliew
Hi Dege, Happy New Year 2019 😀
I have observed poor performance from dgVoodoo2 Glide emulation on accelerated VM using QEMU version 2.12/3.1.0 with WHPX acceleration on Windows 10 x64 Build 1803. I could not explain such slow-down other than the thoughts that dgVoodoo2 Glide emulation may have internal frame time calculation based on _grBufferSwap(int swap_interval) or the new FIFO buffering of Glide calls is messing up the timing within dgVoodoo2. OpenGlide and psVooodoo do not heed the swap_interval from _grBufferSwap(), they just flush out the rendering as fast as they can. Hence, both of them perform better than dgVoodoo2 on accelerated VM, to the point of absurdity that they render Unreal fly-by timedemo on VM faster than dgVoodoo2 natively 😲 This is unbelievable, and something must have gone wrong within dgVoodoo2 Glide emulation with very fast CPU.
Check out the screenshot. This is psVoodoo on QEMU with acceleration. Both OpenGlide and psVoodoo are achieving ~47FPS average with the highest FPS hitting the limit of V-Sync at 60FPS, while dgVoodoo2 crawling around 22FPS on average *on the host machine*. Perhaps, you can look into why dgVoodoo2 Glide emulation is so slow with Unreal even on the host machine. When I switched out dgVoodoo2 with OpenGlide or psVoodoo on the host machine, Unreal fly-by timedemo literally was rendered at the limit of V-Sync. The problem with dgVoodoo2 is evident with high-resolution, especially at 1024x768. However, there are exceptions, so far Quake2 and Turok 2 do not have the slow-down problem with dgVoodoo2. Other than Unreal, NFS3 also has the same problem using the Glide2x thrashing driver from the retailed CD.
FYI, all the testing were done on my desktop with High DPI display and Windows 10 display scaling at 125%. Not sure if this would matter for dgVoodoo2. And my GPU is an old NVIDIA G210 with Direct3D level 10_1 and WDDM1.2.