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

Schedules and announcements about program releases.

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

Postby kjliew » 2019-1-10 @ 21:55

DosFreak wrote:Mingw is still being updated.

I doubt. I am using mingw-get to manage MinGW.org packages and I think I had never seen anything getting update. Packages such as mingwrt and w32api are fixed at 5.0.2 for years with GCC 6.3.0 and binutils-2.28. However, I am not complaining as things were worse before that I had to compile my own GCC and binutils. There seems to be some focus on the WSL development but that was not what I would switch to. And MSYS2/MinGW-w64 is maturing and I am almost totally migrated over there. I only keep MinGW.org for older codes which was initially developed there. For any new development, I think MSYS2/MinGW-w64 is the way to go, especially for the native WIN64 build.
kjliew
Member
 
Posts: 287
Joined: 2004-1-08 @ 03:03

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

Postby DosFreak » 2019-1-10 @ 23:21

Like alot of projects that don't post nightly SVN builds you'll have to compile yourself.

I worked with ghandig on figuring out an SSE issue a year back which prevented programs compiled with mingw from working on operating systems without SSE support which was put into mingwrt 5.0.2 which was released that Dec 2017.

Also https://sourceforge.net/p/mingw/mingw-o ... runk/tree/

Yeah mingw activity is nowhere as high as mingw-w64 and you're probably better off with mingw-w64 but mingw is still being updated so if you don't open a ticket for an issue that's really on you.
User avatar
DosFreak
l33t++
 
Posts: 10054
Joined: 2002-6-30 @ 16:35
Location: Your Head

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

Postby kjliew » 2019-1-11 @ 05:39

Patch updated in 1st post. No change to guest wrappers.

Improved LFB shared memory implementation to work for the peculiar Glide 2.1.1 LFB semantics when using Glide2x to emulate Glide 2.1.1 APIs.
kjliew
Member
 
Posts: 287
Joined: 2004-1-08 @ 03:03

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

Postby robertmo » 2019-1-11 @ 15:02

adding
--disable-stack-protector
to configure
makes msys2 ming64 compile a working .exe
if you want to read about it:
https://www.mail-archive.com/qemu-devel ... 57409.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832
-------------------------
the new 3dfx patch made msys2 ming32 produce a working .exe too
-------------------------
other thing is both exes quit qemu when initialising glide:

testXX.exe

glidept: DLL loaded - glide2x.dll
trace: _grGlideGetVersion@4 called
glidept: grGlideGetVersion Glide 2.43

pressing any key:

trace: _grGlideInit@0 called
glidept: grSstWinOpen called, buf 2 aux 1 gLfb 0xfb000000
User avatar
robertmo
l33t
 
Posts: 4454
Joined: 2003-6-18 @ 10:35

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

Postby kjliew » 2019-1-11 @ 16:07

robertmo wrote:other thing is both exes quit qemu when initialising glide:

Perhaps you are not using dgVoodoo2. If you are not compiling your own open-sourced glide wrappers such as OpenGlide or psVoodoo, then the only prebuilt glide wrapper that works is dgVoodoo2. Or, QEMU 3Dfx requires additional configuration option in glide.cfg to spawn glide rendering window instead of rendering into the same QEMU window. Your console trace looked like QEMU crashed when glide wrapper was taking over.
Code: Select all
 $ echo "CreateWindow,1" > glide.cfg

viewtopic.php?f=24&t=60950#p682545

When everything works, this is what you should be getting in console output. The example is running TEST04 from 3Dfx SDK.
Code: Select all
glidept: DLL loaded - glide2x.dll
trace: _grGlideGetVersion@4 called
glidept: grGlideGetVersion  Glide 2.45 - OpenGLide 0.09rc9
trace: _grGlideInit@0 called
glidept: grSstWinOpen called, buf 2 aux 1 gLfb 0xfb000000
glidept: LFB mode is Shared Memory (fast)
     window 640x480
glidept: grSstWinClose called
glidept: grGlideShutdown called, fifo 0x00be data 0x0dae shm 0x00436b8 lfb 0xfb000000
glidept: DLL unloaded

Well, dgVoodoo2 requires beefy GPU shaders and tend to be slow on older generation of GPUs when the GPU shaders are overloaded.
kjliew
Member
 
Posts: 287
Joined: 2004-1-08 @ 03:03

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

Postby robertmo » 2019-1-11 @ 16:31

quiting after this now when i click on the new window that is black:

glidept: DLL loaded - glide2x.dll
trace: _grGlideGetVersion@4 called
glidept: grGlideGetVersion Glide 2.43
trace: _grGlideInit@0 called
glidept: grSstWinOpen called, buf 2 aux 1 gLfb 0xfb000000
window 640x480
glidept: LFB mode is Shared Memory (fast)
User avatar
robertmo
l33t
 
Posts: 4454
Joined: 2003-6-18 @ 10:35

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

Postby kjliew » 2019-1-11 @ 16:42

robertmo wrote:quiting after this now when i click on the new window that is black:

Just don't click on the Glide window. It will crash. You can only click on QEMU window. Unfortunately, using separate Glide rendering window is a debug mode which I don't have plan to make it better. For simplicity sake, just use dgVoodoo2 for same-window rendering.
kjliew
Member
 
Posts: 287
Joined: 2004-1-08 @ 03:03

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

Postby robertmo » 2019-1-11 @ 16:47

ok works in that window when i disabled -accel hax
User avatar
robertmo
l33t
 
Posts: 4454
Joined: 2003-6-18 @ 10:35

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

Postby robertmo » 2019-1-11 @ 16:49

glidept: DLL loaded - glide2x.dll
trace: _grGlideGetVersion@4 called
glidept: grGlideGetVersion Glide 2.43
trace: _grGlideInit@0 called
glidept: grSstWinOpen called, buf 2 aux 1 gLfb 0x11400000
window 640x480
glidept: LFB mode is Shared Memory (fast)
301 frames in 5.0 seconds, 60.0 FPS
User avatar
robertmo
l33t
 
Posts: 4454
Joined: 2003-6-18 @ 10:35

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

Postby kjliew » 2019-1-11 @ 16:57

robertmo wrote:ok works in that window when i disabled -accel hax

Intel HAXM acceleration for QEMU is not as robust as WHPX on Windows 10 or KVM on Linux. Unfortunately, it is the ONLY way to run QEMU accelerated for i686 build. It usually works for running Linux as its focus mostly for running Android emulator on Windows.

In future, I believe Intel HAXM will be fading away, as the 3 main OS camps now shipped with their own user-space APIs for hardware accelerated VM.
KVM on Linux as the pioneer, WHPX on Windows 10 and HVF on MacOS.
kjliew
Member
 
Posts: 287
Joined: 2004-1-08 @ 03:03

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

Postby robertmo » 2019-1-11 @ 17:11

can you enclose glide.cfg file?
User avatar
robertmo
l33t
 
Posts: 4454
Joined: 2003-6-18 @ 10:35

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

Postby kjliew » 2019-1-11 @ 17:16

robertmo wrote:can you enclose glide.cfg file?

Why? You should try not to use any of the options. They are meant for debugging and cross checking.
kjliew
Member
 
Posts: 287
Joined: 2004-1-08 @ 03:03

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

Postby robertmo » 2019-1-11 @ 17:19

you said we can modify it:
kjliew wrote:It is now possible to choose the LFB mode, MMIO Handlers (slow, accurate) or Shared Memory (fast, approximate) using glide.cfg file.
User avatar
robertmo
l33t
 
Posts: 4454
Joined: 2003-6-18 @ 10:35

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

Postby kjliew » 2019-1-11 @ 17:26

Fine... Here's the list of options available from glide.cfg:
CreateWindow,1
Forced Glide rendering into separate spawned window.
ScaleWidth,[width]
Scale Glide resolution to width. Only work with dgVoodoo2 and psVoodoo.
LfbHandler,1
Forced LFB mode to use MMIO handlers, slow but more accurate. Extremely slow on accelerated VM.

Just create a text file glide.cfg in the startup folder of QEMU. For eg.
Code: Select all
CreateWindow,1
ScaleWidth,1024
LfbHandler,1
kjliew
Member
 
Posts: 287
Joined: 2004-1-08 @ 03:03

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

Postby kjliew » 2019-1-11 @ 19:24

robertmo wrote:adding
--disable-stack-protector
to configure
makes msys2 ming64 compile a working .exe

By the way, I don't think this is necessary if you keep the MSYS2/MinGW-w64 current. I had built QEMU without it and it worked. The GCC from MSYS2/MinGW-w64 is pretty current and updated especially for the x86_64 compiler. However, the configure option is good to get rid of libssp-0.dll dependency, so that Windows version binary distribution does not need to include the additional DLL.
kjliew
Member
 
Posts: 287
Joined: 2004-1-08 @ 03:03

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

Postby robertmo » 2019-1-11 @ 20:54

may be easily reproducible:
install msys2-x86_64-20180531.exe from http://www.msys2.org to a new separate folder
pacman -Syu
restart the MSYS2 console
pacman -Su
pacman -S --needed base-devel mingw-w64-x86_64-toolchain git python
pacman -S --needed mingw-w64-x86_64-glib2 mingw-w64-x86_64-gtk3 mingw-w64-x86_64-SDL2
pacman -S --needed mingw-w64-x86_64-capstone
start mingw64 console
./configure --target-list=x86_64-softmmu
make

this might also bring further light to why dgvoodoo2 doesn't generate picture for me in qemu's window and i have to use glide.cfg CreateWindow,1 setting

btw Pyl works even "better" with glide as in software mode it is either sound or picture ;) depending on your pyl sound setting (any sb or none) ;) Though it works with Haxm in soft mode ;)
User avatar
robertmo
l33t
 
Posts: 4454
Joined: 2003-6-18 @ 10:35

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

Postby kjliew » 2019-1-11 @ 21:19

robertmo wrote:./configure --target-list=x86_64-softmmu

The QEMU target should be i386-softmmu. You only need WIN64 build for better performance, not the x86_64 emulator. In fact, x86_64 emulator will be slower and no 3Dfx Glide would ever require x86_64 instruction emulation.
However, this has nothing to do with dgVoodoo2 not rendering into the same QEMU window. I just tried my x86_64 QEMU build and dgVoodoo2 worked just fine on the same QEMU window. Forcing Glide to render into separate window is of no fun at all.

What version of QEMU are you using? Can you share your QEMU configure summary listing?

Well, the dgvoodoo.conf has option to work better with QEmu.
Code: Select all
Environment                          = QEmu

But it is not a must for dgVoodoo2 to take over the QEMU window. As I had already mentioned earlier, dgVoodoo2 window hooking is very robust and magical.

robertmo wrote:btw Pyl works even "better" with glide as in software mode it is either sound or picture ;) depending on your pyl sound setting (any sb or none) ;) Though it works with Haxm in soft mode ;)

I don't quite get the meaning. Were you able to get it working with 3Dfx Glide or just software rendering? Yeah, accelerated QEMU can be very fast for software rendering, too, if the software rendering is capable of similar visual effects as hardware rendering, but high resolution will not be sustainable. 640x480x16bpp should be fine with today's >3GHz CPUs.
Last edited by kjliew on 2019-1-11 @ 23:09, edited 1 time in total.
kjliew
Member
 
Posts: 287
Joined: 2004-1-08 @ 03:03

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

Postby kjliew » 2019-1-11 @ 22:33

I see that you are interested in getting Pyl (Dust) working and it's a DOS game. Well for DOS Glide, most likely QEMU TCG would be better for a couple of reasons:-
1. DOS Glide games are mostly early Glide games and their target CPU performance (anything less than P166MMX) is achievable with QEMU TCG with a reasonably fast modern CPUs. Examples Tomb Raider 1, Blood 1.
2. Early DOS Glide games which target Voodoo1 hardware are notorious of insane/abusive LFB access. They would just lock the LFB once and treat it as dumb frame buffer. This sounds silly but 3Dfx actually allowed this for Voodoo1 hardware, Carmageddon 1 an example of such silly LFB access. This would later haunt 3Dfx in revising the APIs to enforce better LFB sanity. For those, yeah, you will need the "LfbHandler,1" option and forget about accelerated VM.
3. DOS Glide games with poor frame rate regulation. For those, while accelerated VM works for them, it makes them too fast and the games exhibit "Matrix" slow-motion effect in animation, even though the QEMU console perfstat logged at constant 60FPS. Redguard and Blood 1 are examples of this. Tomb Raider 1 is a remarkable exception as it fixed its frame rate at constant 30FPS regardless of how fast the frame time. As a result, Tomb Raider 1 works out pretty well on either QEMU TCG or QEMU with acceleration. The later may be useful for low-end mobile CPUs, otherwise, it is a moot point for going into acceleration for nothing when QEMU TCG already provides constant 30FPS.
kjliew
Member
 
Posts: 287
Joined: 2004-1-08 @ 03:03

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

Postby robertmo » 2019-1-13 @ 17:14

a new problem but nothing to do with 3dfx patch as it happens with a plain qemu 3.1.0 build too

\qemu>qemu-system-x86_64.exe -accel whpx
Windows Hypervisor Platform accelerator is operational

geting this soon after starting (without boot image while qemu looks for boot disk)
or with a simple "dir" when booted to dos with no autoexec.bat
or lots of other cases at the exact same moment generally at the very beginning of different types of boot of windows

qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2
qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor

looks the guy here encountered exactly the same error later in his deduction and somehow hacked it:
https://github.com/xqemu/xqemu/issues/112
User avatar
robertmo
l33t
 
Posts: 4454
Joined: 2003-6-18 @ 10:35

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

Postby robertmo » 2019-1-13 @ 21:00

as for a previous problem I finally got glide working in qemu window using:
SDL support yes (1.2.15)
GTK support no
GTK GL support no
User avatar
robertmo
l33t
 
Posts: 4454
Joined: 2003-6-18 @ 10:35

PreviousNext

Return to Release Announcements

Who is online

Users browsing this forum: No registered users and 2 guests