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

Schedules and announcements about program releases.

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

Postby kjliew » 2018-6-27 @ 23:01

Last Update - 2019/05/25
This is a significant update to QEMU 3Dfx Glide pass-through. Finally, I had spent some time updating the implementation for a complete guest push model that supports shared memory FIFO to buffer up the Glide calls and data so that they are sent into host in bulk. All modern GPUs like this pattern of workload. This enables QEMU TCG to stay longer in the recompiler and run translated code blocks instead of breaking out frequently to service MMIO. Overall, this improves the efficiency of QEMU TCG which turns into 25~30% improvement in game speed. Well written games, ie. games which practice sane LFB semantics benefit the most. For example, GLQuake and Quake2 show similar performance stats as DOSBox with its superfast dynamic x86 core. Furthermore, the best thing about guest push model with shared memory FIFO is hardware accelerated VM, such as KVM in Linux and WHPX in Windows 10. Both HW accelerated VM are able to accelerate well behaved DOS4GW and Windows games at 2~3x the in-games FPS compared to QEMU TCG. This would make post-2001 era 3Dfx Glide games completely playable on modern machines, some may even be too fast to play. It also makes less demanding games play well on less powerful thin-and-light laptops that have CPU < 2GHz (Celeron 1037U/2955U/Core i3-4010U/AMD C60/E2-7110). For example, Turok 2 which uses Glide3x API, is unplayable with QEMU TCG, average about 22fps, most of the time around 15fps and perhaps worst cases at single digit FPS. When using WHPX accelerated QEMU, Turok 2 average about 67fps and worst case perhaps around 45fps.

So far, I had only tested KVM in Linux and WHPX in Windows 10. WHPX is only available on Windows 10 x64 Build 1803 onward, and it requires QEMU version 2.12 or newer. KVM in Linux is a long matured technology and well supported by QEMU. WHPX is quite new in the Windows world, it runs Linux VM on Windows pretty well, but not very good at running older Windows version on Windows 10. So far, I can only get it running with ACPI Standard PC HAL on Win2k/XP, so no SMP on VM. On the other hand, KVM in Linux runs Windows VM very well, including support for SMP HAL.

In general, early 3Dfx Glide games (1995~1997) would run best with DOSBox or QEMU TCG. They tend to employ abusive/insane LFB semantics that neither SW nor HW virtualization techniques can do anything to speed up. Everything goes down to raw CPU physical processing power and the overhead of breaking out of recompiler to handle MMIOs. I think DOSBox is especially efficient and has the least overhead of handling MMIOs, QEMU TCG comes next and HW accelerated VM (KVM/WHPX) would be the worst. Update (2019/01/02): 3Dfx demos "Valley of Ra" and "Race" are starting up with "ShamelessPlug" enabled. This is causing huge slow-down with KVM/WHPX. Once this was disabled by "Ctrl-S", the demos would also run at improved FPS with WHPX/KVM. While the performance hit of "ShamelessPlug" is negligible with QEMU TCG (at 1-2fps drop), it kills almost 90% of the performance of KVM/WHPX perhaps by too frequent VMEXIT. Update (2019/01/10): With LFB mode using shared memory, the performance hit of "ShamelessPlug" with accelerated VM has been greatly reduced. In Win98, 3Dfx demo "Valley of Ra" would run at over 95fps initially with "ShamelessPlug" enabled. And with "ShamelessPlug" disabled, it would run at over 109fps. Thanks to HW accelerated virtualization, this is currently the highest performance 3Dfx Glide virtualized solution.

Late 3Dfx Glide games (1997~demise of 3Dfx) have no issue with abusive/insane LFB semantics, but they are the era of PentiumII/III/Athlon/MMX/SSEs CPU requirements that pure software simulation/recompilers are not yet fast enough to run them. I am pleased and delighted to provide the solution to run them on accelerated VM of present day modern CPUs on modern OSes. I hope the solution will be useful in the future and there will always be ways to run 3Dfx Glide games.

Games work extremely well on accelerated VM. They do not directly access LFB during game play.
GLQuake, Quake2, Quake3, Turok1, Turok2, Half-Life, Unreal, Nightmare Creatures, Nuclear Strike, NFS2 SE and probably others using similar game engines.

[FIXED]Games still playable but intro/cut-scenes are rendered through LFB, which will be missed.
NFS3, NFS 2000 Porche

[FIXED]Unplayable as game briefing or part of the in-game menu rendered through LFB, but in-game action is fine.
Descent Freespace, Freespace 2, Homeworld

[FIXED, well...]Craps, constant and continuous abuse of LFB while game in action
Mech2 31st, Titanium Mech2 series, Heavy Gear 1. These games work best on Win98, but Win98 has startup/shutdown problem when used in accelerated VM, and sometimes some DLLs won't load ( I dunno why). If all these were passed and the game did not complain about DLLs, then it works. If these games were patched to run on Win2k/WinXP, they must not be run with compatibility. The WinXP app compatibility layer is not optimized for WHPX/KVM, it will run very slow, much slower than on Win98 with QEMU TCG. I have never seen Titanium Mech2 series running at such speed, almost locked at 60FPS, regardless of any in-game action, up to 4 Mechs in battle with particle trails and chunky explosions. Unfortunately, this game has known issue for being too fast, the jumpjet recharge rate becomes too slow at 60FPS. That would make me think that if I had a Core 2 Duo 3GHz running Win98, then the game will be really, really fast.

Next is to look into alternative LFB implementation strategy to make the "Unplayables & Craps" work with accelerated VM. That will likely involve heavy memory copying between shared memory and host LFB instead of existing LFB memory handlers in VM. For QEMU TCG, LFB memory handlers seem to be sufficient as observed from NFS3 intro scene, the animation is smooth. It is interesting to understand if memory copying would still be fine for QEMU TCG or only useful when VM is accelerated.

Update 2019/01/06 New LFB implementation with shared memory. This fixes the game intro/cut-scene/briefing rendered through LFB and make them work with accelerated VM.
Update 2019/01/10 LFB implementation with shared memory also work for the peculiar Glide 2.1.1 LFB semantics when using Glide2x to emulate Glide 2.1.1 APIs, but so far only dgVoodoo2 and I only have 2 games tested, Mech2 31st and Pandy. It is now possible to choose the LFB mode, MMIO Handlers (slow, accurate) or Shared Memory (fast, approximate) using glide.cfg file.
Update 2019/01/15 Minor bug fixes for shared memory LFB mode.
Update 2019/01/30 Fixed QEMU acceleration hung on Pyl. Shared memory LFB mode support for AUX/DEPTH buffer. Optimized LFB read lock to minimize copy overhead.
Update 2019/02/04 Added option to fake LFB locks for AUX/DEPTH buffer without passing through into Glide wrappers, especially for Glide wrappers that do not support it.
Update 2019/02/08 Added option to merge LFB writes to BACK buffer. Improved performance and compatibility of OpenGlide for games that do multiple lock/unlock within a frame (eg. Pyl, Archimedean Dynasty).
Update 2019/05/25 Support DJGPP DXE for 3Dfx OpenGL through Mesa 3D library.

Refer to the following thread for list of configurable options.
viewtopic.php?f=24&t=60950&start=40#p726146

3Dfx Glide lives on!
Attachments
wrapper_guest-20190525.zip
Prebuilt binaries for guest wrappers
(121.14 KiB) Downloaded 72 times
qemu64-3dfx-20190525.tar.gz
QEMU 3Dfx Glide pass-through
(46.71 KiB) Downloaded 81 times
openglide_linux_window-1.diff
OpenGlide X11 window init
(2.94 KiB) Downloaded 99 times
Last edited by kjliew on 2019-5-26 @ 09:33, edited 38 times in total.
kjliew
Member
 
Posts: 443
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby t9999clint » 2018-6-28 @ 00:21

This sounds really interesting, I am very curious to see the performance of this on Linux when that bit is done.
GLIDE passthrough + KVM would be pretty epic.
User avatar
t9999clint
Member
 
Posts: 157
Joined: 2014-10-07 @ 14:08
Location: Edmonton, Canada

Re: QEMU 3Dfx Glide Pass-Through

Postby Stiletto » 2018-7-01 @ 14:33

BTW kjliew: due to this development, I've put a bug in the ear of Dege's "competitor" Zeus regarding a 64-bit build of nGlide (closed source), though time will tell if he'll actually do it. Surprised you haven't tested the 32-bit version of nGlide yet though.

If you're feeling really daring, kjliew, you could try making a 64-bit compile of dgVoodoo 1.40 or 1.50 Beta3:
http://www.vogonsdrivers.com/getfile.ph ... state=53,0
http://www.vogonsdrivers.com/getfile.ph ... state=53,0
But the build process sounds quite challenging to begin with, I don't want to think what would happen if you tried...

Even crazier/hilarious, you could try testing:
- Zeckensack 0.84c (OpenGL, glide2x/glide3x, closed source, 32-bit only): http://www.zeckensack.de/glide/
- SvensWrapper (OpenGL, glide2x through a special file/primarily glide3x, closed source, 32-bit only): http://www.svenswrapper.de/english/
- SvensWrapper glide3x-only with GlideXP's Glide2x->Glide3x translator (could possibly work, IDK, I've never tried: https://wenchy.net/old/glidexp/ )
- uGlide (Direct3D, glide2x, closed source, 32-bit only, but recently active: could request they make a 64-bit build tho): http://www.hedgehogeyes.com/uglide.html
- some version of Glitch64 (OpenGL, glide3x, open source, 32-bit only) combined with GlideXP: http://www.vogonsdrivers.com/wrappers/f ... /Glitch64/
- the final release of eVoodoo (Direct3D, glide2x/glide3x, closed source, 32-bit only): http://www.vogonsdrivers.com/wrappers/f ... D/evoodoo/
(for more from before the modern wrapper era, and more mirrors, see: http://www.vogonsdrivers.com/wrappers/files/Glide )
Crazy I know, but I think it'd be funny to see the compatibility testing, and among other things, would be funny to see someone build something new out of Glitch64... you could maybe even build a new different Glide wrapper out of its source, IDK.

PS. don't forget to check on your psVoodoo thread, I sent Glidos a PM about it.
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto
User avatar
Stiletto
l33t
 
Posts: 4351
Joined: 2002-7-01 @ 21:57

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-01 @ 19:51

Greetings Stiletto, my friend!

Stiletto wrote:BTW kjliew: due to this development, I've put a bug in the ear of Dege's "competitor" Zeus regarding a 64-bit build of nGlide (closed source), though time will tell if he'll actually do it. Surprised you haven't tested the 32-bit version of nGlide yet though.


I wanted to try out nGlide, but the current problem is - it doesn't support windowed mode, and I am having problem with QEMU SDL1/2 windowing code not allowing Glide wrappers to hijack its window :dead: OpenGlide, psVoodoo and dgVoodoo all are supporting windowed mode. When I started to have Glide wrapper rendered into the same QEMU window instead of spawning a new window, which I did initially to get around the problem so that I can focused on the pass-through implementation, only dgVoodoo2 is capable of managing its window sizing on its own, and I don't know what magics Dege had on dgVoodoo2. I have to remove the window sizing code from OpenGlide and PsVoodoo for them to work.

And, thanks for your kind attention on getting in touch with nGlide author, Zeus. I had thought of contacting him myself initially. I had worked with Dege in the past, so I started with him on dgVoodoo2. And there is still a lot to do before checking out other Glide wrappers, I decided to move on with dgVoodoo2.

Stiletto wrote:If you're feeling really daring, kjliew, you could try making a 64-bit compile of dgVoodoo 1.40 or 1.50 Beta3:
http://www.vogonsdrivers.com/getfile.ph ... state=53,0
http://www.vogonsdrivers.com/getfile.ph ... state=53,0
But the build process sounds quite challenging to begin with, I don't want to think what would happen if you tried...

Oh yeah, you read my mind. I was actually thinking of doing this, reviving only the Glide wrapper part of dgVoodoo1.50Beta3. The plan is to get modern GCC to build dgVoodoo1 with GNU Makefile instead of VS. I have already done this for PsVoodoo. DgVoodoo1 is of particular interest because of its accurate implementation of Glide APIs. I remembered I compared its rendering output side-by-side with a real Voodoo2 back then, and for the stuffs that I care, they were mostly indistinguishable.
kjliew
Member
 
Posts: 443
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby Stiletto » 2018-7-02 @ 01:06

For what it's worth, these guys seem to be collecting OpenGlide patches above and beyond what's contained in OpenGlide CVS (I may be mistaken): https://github.com/voyageur/openglide/commits/master

(This might be moot provided I prodded Glidos hard enough :D )
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto
User avatar
Stiletto
l33t
 
Posts: 4351
Joined: 2002-7-01 @ 21:57

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-06 @ 10:53

Updated patch for QEMU 3Dfx Glide pass-through in 1st post.

For 32-bit build, it is now possible to check out other closed source Glide wrappers (especially those that only support full screen rendering) by having Glide wrapper rendering into its own window. To enable this, create a CFG file from the startup location of QEMU.
Code: Select all
 $ echo "CreateWindow,1" > glide.cfg


So far, here's my own results on Windows 10 x64 with 32-bit QEMU:
- Zeckensack 0.84c - worked fine in full screen, no windowed mode. It stole input focus from QEMU, but can Alt-Tab for QEMU to regain inputs.
- nGlide 2.00 - worked fine in full screen on initial launch, crashed on shutting down Glide. It stole input focus from QEMU, but can Alt-Tab for QEMU to regain inputs.
- dgVoodoo1 - worked fine in its own window. Full screen stole input focus from QEMU and Alt-Tab returned to window mode. So full screen cannot be used due to lack of inputs.

Both full screen and own window rendering have issue with mouse clicks. This is a major problem in full screen mode because the clicks have no other place to go. For own window rendering, as long as the clicks stay within QEMU window, then it is fine, otherwise Glide render window will crash.

I am still looking for solution to these issues. Personally, I highly prefer Glide render into the same QEMU window. Mouse clicks on games just work, better shooting in games where mouse usage matters. And I always prefer to have my games in windowed mode, even though it is just 640x480.
kjliew
Member
 
Posts: 443
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-07 @ 22:10

Updated 1st post with new patch that support Linux on both SDL1/SDL2.
As native 64-bit binary, QEMU TCG is significantly faster than DOSBox dynrec CPU core.
kjliew
Member
 
Posts: 443
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby Stiletto » 2018-7-08 @ 23:47

Weird wrapper tricks suggestion - QEMU 3Dfx Glide pass-through compiled for Windows 2000, running on Win2K Host OS, with Rendition Verite V2200 and BigRRed. :D :D :D

Wish I had a decent desktop, I'd love to try my weirder wrapper suggestions (SvensWrapper+GlideXP, Glitch64+GlideXP, eVoodoo2+3, uGlide) and do some compatibility testing just to see how broken they are. I miss my old days of wrapper compatibility testing :)
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto
User avatar
Stiletto
l33t
 
Posts: 4351
Joined: 2002-7-01 @ 21:57

Re: QEMU 3Dfx Glide Pass-Through

Postby t9999clint » 2018-7-10 @ 22:04

kjliew wrote:Updated 1st post with new patch that support Linux on both SDL1/SDL2.
As native 64-bit binary, QEMU TCG is significantly faster than DOSBox dynrec CPU core.

Now that sounds like something for me to try this weekend... :happy:
User avatar
t9999clint
Member
 
Posts: 157
Joined: 2014-10-07 @ 14:08
Location: Edmonton, Canada

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-15 @ 08:14

Patch updated for more robust Linux support and better handling of QEMU window sizing when _grSstWinOpen and _grSstWinClose are called repeatedly without calling _grSstGlideShutdown (as in 3Dfx Glide TEST27 and TEST30).
kjliew
Member
 
Posts: 443
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-16 @ 05:48

One major advantage of QEMU is the networking support. Thanks to its enterprise grade virtualization, the networking support has to be solid. Quake2 multiplayer just work out-of-box within QEMU. If connecting to external server, even the simplest SLIRP user networking backend works. I also tried out older games, Mechwarrior 2 3Dfx NetMech works with winsock TCP for local LAN play, but this requires more complicated networking setup for QEMU to use tuntap networking. Wow! :happy: However, I couldn't get IPX/SPX to work. The protocol was installed correctly and the games could see it, but the VM could not see each other. I have yet to try hard enough, such as disabling firewall and messing around with router's configuration.

Head-to-head null-modem setup is a swift configuration for QEMU. The serial ports of 2 VMs can be virtually connected through TCP for local LAN play, as simple as that. That was how I tried out MercNet 3Dfx from the Titanium series. Too bad, MercNet does not support winsock TCP, its Internet play over TCP/IP requires connection to Battle.net. So that leaves null-modem as the only multiplayer option for head-to-head play.
kjliew
Member
 
Posts: 443
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby wadrasil » 2018-7-18 @ 01:36

Hello,

I wanted to thank you very much for this work! Thanks! I have not tried using it but i am very excited to try this out.

I wanted to ask a few questions about using this, I apologies if these are simple or rude questions.
Do you plan to or have your patches been submitted to qemu.org?
You stated this works works via a proprietary nvidia driver, has this been tested with the nouveau driver or any radeon drivers?
You mentioned this works via TCG not KVM correct? What guest OS's does this work on or has been tested on?
What command line options are needed for qemu for this to work on the guest?

I have compiled Qemu on arm hosts before and have used qemu-system-x64 to run Windows guests and some games like Starcraft and Diablo and they work fine, wondering if this might work for arm since they have boards with pcie slots now and have open source drivers for nvidia and radeon. Thanks again for this awesome patch!
wadrasil
Newbie
 
Posts: 3
Joined: 2014-8-07 @ 11:18

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-18 @ 19:33

wadrasil wrote:Do you plan to or have your patches been submitted to qemu.org?

Judging from the enterprise nature of QEMU, I am not sure if this patch will be relevant to their mission, and I don't have the time to commit to long-term support for this feature to keep it alive. For now, it would stay as a patch from vogons.org. I have no objection if anyone would try to upstream it.
wadrasil wrote:You stated this works works via a proprietary nvidia driver, has this been tested with the nouveau driver or any radeon drivers?
You mentioned this works via TCG not KVM correct? What guest OS's does this work on or has been tested on?

The 3D acceleration part is offload to host Glide wrappers. For Linux, so far OpenGlide is the only one, and it is wrapping into OpenGL. As long as the drivers provide good OpenGL and OpenGlide is happy, it should work. I have tried the following guest OSes, Win98SE, Win2K SP4 and WinXP SP3. DOS support is coming, but DOSBox is always better on DOS due to its excellent audio hardware emulation.
wadrasil wrote:What command line options are needed for qemu for this to work on the guest?

No command line options are required. Once the patch is applied, the feature is always available. I tried keeping the patch at very minimum to avoid invasive changes to QEMU core and standard device model interfaces. The Glide pass-through itself is implemented as standard QEMU device model. Host Glide wrappers are loaded dynamically upon Glide activation, so as to keep the rest of QEMU functional when Glide wrappers are missing on host. On Windows host where there are more than 1 choice for Glide wrappers, one can switch to different Glide wrappers without restarting QEMU simply by replacing the DLLs.
wadrasil wrote:I have compiled Qemu on arm hosts before and have used qemu-system-x64 to run Windows guests and some games like Starcraft and Diablo and they work fine, wondering if this might work for arm since they have boards with pcie slots now and have open source drivers for nvidia and radeon.

At high-level, if you can get OpenGlide compiled and working on ARM host, then it is very likely that this will work. If OpenGlide can be ported to OpenGL ES, then it could have also worked on mobile graphics such as Adreno or Mali.
kjliew
Member
 
Posts: 443
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-21 @ 07:39

Patch updated, support Glide pass-through for DOS games. So far, here's the list of games I had tested:
- Blood (dgVoodoo2, psVoodoo)
- Tomb Raider I/Unfinished Business (OpenGlide, dgVoodoo2, psVoodoo)
- BC3000AD 2.09 freeware (dgVoodoo2)
- Carmagaddon 1 3Dfx (OpenGlide, dgVoodoo2, psVoodoo)
- Redguard 3Dfx demo (OpenGlide, dgVoodoo2, psVoodoo)
- Extreme Assault 3Dfx demo (dgVoodoo2)
- Archimedean Dynasty 3Dfx demo (dgVoodoo2)

Battle Cruisers 3000 A.D. must be run from Win98 DOS prompt. It is a DOS/4GW app, but I found that it only worked from Win98 DOS prompt and not pure DOS. I couldn't get it to work in Win98 from DOSBox or pure DOSBox, so this is something to cheer about as we can now play this game with 3D acceleration on Windows 10. I think this game was developed with Windows in mind and though it is a protected-mode DOS program, it may have used DPMI service calls specific to Win98 DOS environment. or its non-DPMI code paths were buggy and never tested. I couldn't believe it that a DOS/4GW app didn't find real-DOS the best way to run that it didn't have the deal with the crappy VCPI/DPMI service calls.

Update: More DOS games checked out.
Last edited by kjliew on 2018-7-26 @ 00:40, edited 2 times in total.
kjliew
Member
 
Posts: 443
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby TomB » 2018-7-24 @ 15:42

Did you remove the patch? I'd really like to try this.
TomB
Newbie
 
Posts: 23
Joined: 2005-7-02 @ 19:14

Re: QEMU 3Dfx Glide Pass-Through

Postby wadrasil » 2018-7-24 @ 17:38

I am hoping the latest patch is still available, I was hoping to try this out soon as well. Especially after the last announcement.
wadrasil
Newbie
 
Posts: 3
Joined: 2014-8-07 @ 11:18

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-24 @ 19:22

I am updating the patch. Will re-post shortly.
Updated patch available. I also added pre-built binaries for wrappers on guest OS - 98ME & DOS - especially for folks checking this out on Linux, so that you don't need to setup VM or cross-compiled to DOS/Win32.
The Win32 wrapper DLLs are built with MinGW/GCC. They can be built to target VXD for 98ME or KMD for 2KXP. The FXMEMMAP.VXD and FXPTL.SYS are standard drivers from 3Dfx driver package.
The DOS wrapper OVL requires Watcom to build.

You *CANNOT* use 98ME wrapper DLLs on WinNT/2k/XP guest OS because of the difference in kernel driver architecture (VXD vs KMD).

I expect most people will check out Win98 as guest OS 1st, since this is the most compatible OS for old games, or just plain DOS. However, if the games are new enough to run on Win2k, then they will typically run faster on Win2k, such as Quake2 and Half-Life.
kjliew
Member
 
Posts: 443
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby TomB » 2018-7-25 @ 10:28

Thanks for the patch. I'm trying to build this on Arch Linux and I get the following errors:

Code: Select all
usr/lib/libc.so.6: warning: defined here
  GEN     aarch64-softmmu/config-target.h
  CC      aarch64-softmmu/hw/3dfx/glidept_mm.o
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c: In function ‘guest_memory_read’:
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:126:5: error: unknown type name ‘X86CPU’; did you mean ‘ARMCPU’?
     X86CPU *cpu = X86_CPU(cs);
     ^~~~~~
     ARMCPU
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:126:19: warning: implicit declaration of function ‘X86_CPU’; did you mean ‘BP_CPU’? [-Wimplicit-function-declaration]
     X86CPU *cpu = X86_CPU(cs);
                   ^~~~~~~
                   BP_CPU
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:126:19: warning: nested extern declaration of ‘X86_CPU’ [-Wnested-externs]
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:126:19: warning: initialization of ‘int *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:127:5: error: unknown type name ‘CPUX86State’; did you mean ‘CPUARMState’?
     CPUX86State *env = &cpu->env;
     ^~~~~~~~~~~
     CPUARMState
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:127:28: error: request for member ‘env’ in something not a structure or union
     CPUX86State *env = &cpu->env;
                            ^~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:130:86: error: request for member ‘eip’ in something not a structure or union
  DPRINTF("Guest vaddr 0x%08x Pagefault read addr 0x%08x len 0x%08x\n", (uint32_t)(env->eip), (uint32_t)vaddr, (uint32_t)len);
                                                                                      ^~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:39:47: note: in definition of macro ‘DPRINTF’
     do { fprintf(stderr, "glidept: " fmt , ## __VA_ARGS__); } while(0)
                                               ^~~~~~~~~~~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c: In function ‘guest_memory_write’:
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:137:5: error: unknown type name ‘X86CPU’; did you mean ‘ARMCPU’?
     X86CPU *cpu = X86_CPU(cs);
     ^~~~~~
     ARMCPU
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:137:19: warning: initialization of ‘int *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
     X86CPU *cpu = X86_CPU(cs);
                   ^~~~~~~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:138:5: error: unknown type name ‘CPUX86State’; did you mean ‘CPUARMState’?
     CPUX86State *env = &cpu->env;
     ^~~~~~~~~~~
     CPUARMState
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:138:28: error: request for member ‘env’ in something not a structure or union
     CPUX86State *env = &cpu->env;
                            ^~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:141:87: error: request for member ‘eip’ in something not a structure or union
  DPRINTF("Guest vaddr 0x%08x Pagefault write addr 0x%08x len 0x%08x\n", (uint32_t)(env->eip), (uint32_t)vaddr, (uint32_t)len);
                                                                                       ^~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:39:47: note: in definition of macro ‘DPRINTF’
     do { fprintf(stderr, "glidept: " fmt , ## __VA_ARGS__); } while(0)
                                               ^~~~~~~~~~~
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c: In function ‘processArgs’:
/home/tom/tmp/qemu-2.12.0/hw/3dfx/glidept_mm.c:312:4: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
    write(fd, s->fbuf, s->flen);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [/home/tom/tmp/qemu-2.12.0/rules.mak:66: hw/3dfx/glidept_mm.o] Error 1
make: *** [Makefile:478: subdir-aarch64-softmmu] Error 2


The errors suggest using ARMCPU instead of X86 is it somehow detecting my cpu architecture wrong? I have an AMD Threadripper 1950x.

I extracted the 3dfx directory from the patch file into the qemu/hw/ directory then ran

Code: Select all
patch -p1 < ./hw/3dfx/3dfx.patch
./configure
make


Am I doing something wrong in the build process?
TomB
Newbie
 
Posts: 23
Joined: 2005-7-02 @ 19:14

Re: QEMU 3Dfx Glide Pass-Through

Postby kjliew » 2018-7-25 @ 17:28

The Glide pass-through device model only works for target i386-softmmu and x86_64-softmmu. Use "configure --target-list=i386-softmmu" to remove the non-x86 targets from build, and this will also speed up QEMU build time.

I would also recommend that the build should be on a separate folder from the source.
Code: Select all
$ tar xf qemu-2.12.0.tar.xz
$ mkdir build
$ cd build
$ ../qemu-2.12.0/configure --target-list=i386-softmmu
$ make
kjliew
Member
 
Posts: 443
Joined: 2004-1-08 @ 03:03

Re: QEMU 3Dfx Glide Pass-Through

Postby TomB » 2018-7-28 @ 12:04

Thanks, that compiled fine and I installed windows98 with your wrapper DLLs. Unfortunately I get a segfault when glide initialises, I'm guessing I need to configure qemu with specific hardware or install some drivers?

I'm using

Code: Select all
qemu-system-i386 -m 1024 -soundhw sb16 --boot order=d -drive file=win9x,format=qcow -vga std


Do I need a different VGA setting for the 3dfx passthrough to work?

(I know that openglide is running correctly because native dosbox works)

edit: I do get this output in the console:

Code: Select all
glidept: DLL loaded - glide2x.dll
glidept: grSstWinOpen called
113434 Segmentation fault 


edit 2: I'm a complete amateur looking through the code but in glidewnd.c, if CONFIG_WIN32 isn't set, init_window doesn't create the window and hwnd is always zero. Should there be a linux version of the call to glide_prepare_window here?
TomB
Newbie
 
Posts: 23
Joined: 2005-7-02 @ 19:14

Next

Return to Release Announcements

Who is online

Users browsing this forum: No registered users and 1 guest