Closed ghost closed 4 years ago
I had only built the code on x86_64 Windows and Linux with GCC. If you are trying to build it for ARM as of RPi4, then you may run into several issues. The __stdcall
keyword is not supported on anything other than i386_x86. You need to add the relevant redefinition for ARM. Here's an example from glide2x_impl.c and mesagl_impl.c.
#if defined(CONFIG_LINUX) && CONFIG_LINUX
#include <dlfcn.h>
#if defined(HOST_X86_64) && HOST_X86_64
#define __stdcall
#endif
#endif
You also need the host platform MESA to support OpenGL, not OpenGL ES because the guest stub does not perform any OpenGL->OpenGL ES translation. This may be technically possible but it is not done. I am not familiar with ARM platforms such as RPi4. You may want to check $ glxinfo
if OpenGL core profile is available.
For how it is going to work with just MESA to emulate 3Dfx Glide API, check out: https://www.vogons.org/viewtopic.php?f=24&t=72859
Rpi4 it's opengl 2.1 desktop profile conformant by Mesa!! Good enough for the software I need.
I had run several desktop games with mesa and box86 https://www.youtube.com/playlist?list=PLhgmBihZpcBxWacPE05P-tN_ZuPBy8cxh
But I got surprised about the qemu performance on master on windows 98 on rpi4. Even without hw acceleration many games are playable, commandos, need for speed 2 se, sims, etc.
https://www.youtube.com/playlist?list=PLhgmBihZpcByDyOIUOkhLy97Q7HDUefcH
I am not a dev, but I have someone in mind than could help us to give support to arm for your project.
LaIt@kjliew okay now it finish... let see.. :)
I have to tell you than if this works you deserve a nobel.
So far nothing, I have to install the "3dfx" gpu drivers or just with the warper it's ok?? If I want to run the test it goes wild glitchy but I see something on the console, mesapt: dll loaded. I have the freeware display driver installed to get 32 bit colours and high res on windows98 etc, I have to remove it? I have to set something on the command line??
Also, when trying nfs2se console says the glide dll was unloaded (the game didn't run) . That said I had to use the original 3dfx glide2x.dll bc the game wont recognize your library.
Also, do you have any discord or IRC channel to stay in touch about this?? I would prefer discord or even hangouts (that last one it's the one I use more)
new retry
ive compiled openglide (didnt know I had) with sdl bc sdl it's giving the best quality so far for my vm and gtk it{s crashing in my side at least on master qemu. I will recompile it without sdl trying to fix it
pi@raspberrypi:~/.w95 $ ./win98.sh glidept: DLL loaded - glide2x.dll glidept: DLL unloaded glidept: DLL loaded - glide2x.dll trace: _grGlideInit@0 called glidept: grSstWinOpen called, fmt 0 org 0 buf 2 aux 1 gLfb 0xc8887000 Segmentation fault
Mesa test keeps crashing.
Let address the issue one at a time. For Glide pass-through, you will need:
For MESA GL pass-through, you will need:
NFS2SE is a well tested game. It works very well with QEMU on x86 PC, fully accelerated through Glide pass-through or MESA GL pass-through with OpenGL-based Glide wrappers.
I don't typically frequent discord or IRC, but I can join #IRC of your choice to get you going on RPi4. Or, we can also meet at #qemu or #dosbox channels.
Ok, I will keep doing research and some workaround, the problem is than if I disable sdl from openglide I cant use sdl2 on my vm (I am right?) Bc gtk it's crashing when utilizing sound. And yes we have libgl and opengl desktop profile 2.1. about IRC we will see later bc IRC is a bit annoying to me and maybe I just need to keep doing research and workarounds, the good thing it's that it compiles hahaha does dx it's planned on the future.. I imagine that it's totally different than opengl... But I dont know
No, you can keep using SDL2 for QEMU. OpenGlide does not depend on QEMU for its rendering. In fact, it hijacked QEMU window to do OpenGL rendering. QEMU with GTK display option is not supported for both Glide and MESA GL pass-through.
So far, I recompiled it without sdl (I had apply the diff before anyway bc I found that on the forum) and it goes a bit longer, it shows the splash (bc I set that) it opened a new window and it goes black screen OpenGLid.log we have 16 texture units, but this shows 8 only, just a glxinfo error. this it's the terminal log
glidept: DLL loaded - glide2x.dll
glidept: DLL unloaded
glidept: DLL loaded - glide2x.dll
trace: _grGlideInit@0 called
glidept: grSstWinOpen called, fmt 0 org 0 buf 2 aux 1 gLfb 0xc8846000
glidept: LFB mode is Shared Memory (fast)
window 640x480
anyway, if opengl doesnt work why it would work glide haha
Glide pass-through sanity check is available here. https://www.vogons.org/viewtopic.php?p=687744#p687744 It will show an RGB iterated colored triangle.
it opened a new window and it goes black screen
If you had patched the OpenGlide, then it should render into the same window of QEMU. I am not sure if this is what you meant by a new window. It seems to me that Glide pass-through is working but there is problem with using the correct window to show the results.
Ryeah, I forgot to patch it (I thought I did and I didnt) , but now it's pathched and it does the same, black screen, but noe on the same windows. I will try the sanity checks.
The sanity check its dos only and seems my dos on win98 vm it's not working. Stub exe filed dos4gw.exe not such..
Thanks for trying to help. But we are on an ending point, nor gl nor glide working.. glide was expected.. but gl?? Weird... I will try than my supporters back you with a pi4. Where are you from @kjliew ?
I just uploaded the same sanity test for WIN32. Check it out. If you can see 3Dfx splash screen from OpenGlide on the same QEMU window, then the host OpenGL rendering context should be working.
no, it fail, it show a triangle and nothing more
glidept: grSstWinClose called
glidept: grGlideShutdown called, fifo 0x00be data 0x0dae shm 0x00436b8 lfb 0xfb000000
glidept: GrState 1 VtxLayout 0
glidept: DLL unloaded
glidept: DLL loaded - glide2x.dll
trace: _grSstControl@4 called
trace: _grSstControl@4 called
trace: _grGlideGetVersion@4 called
glidept: grGlideGetVersion Glide 2.45 - OpenGLide 0.09rc9
trace: _grGlideInit@0 called
glidept: grSstWinOpen called, fmt 1 org 0 buf 2 aux 1 gLfb 0xc8507000
glidept: LFB mode is Shared Memory (fast)
window 640x480
no, it fail, it show a triangle and nothing more
I don't get it. TEST04 is meant to show just a triangle. If you got that, then it passed. Can you be specific on why you think it failed. The console trace looked normal and Glide pass-through working for TEST04.
I dont know, I was expecting something moving like glxgears.. not just a triangle. it's supposed to be a 3d api, not a triangle maker
I uploaded another TEST25. This one has textures and spinning triangle. I think Glide is working. It may take some time for NFS2SE to load if this was the game you were trying earlier. I can't estimate how fast QEMU TCG can run x86 codes on ARM. On the Core m3-6Y30 ultrabook, it took about 5 second for NFS2SE demo to show up after OpenGlide 3Dfx splash screen.
If you are looking for more game-like 3D demo, then you can download 3Dfx tech demos at
https://falconfly.vogonswiki.com/artwork.html
Valley of Ra
and Race
are good ones.
Now you have Glide pass-through working, you may want to retry wglgears demo for MESA GL pass-through. I guess you didn't get it working last time because you were missing the 3Dfx kernel driver shared by all the guest wrapper DLLs.
It was almost instantly on software mode but i will try another game. No, i have all the libraries etc on the same folder, gl doesnt work.
@kjliew mmm race need apilib.dll
The invalid instruction is an i686 CMOV! What CPU had you chosen for QEMU? You should emulate at least an i686-class CPU. Never had I thought that ARM compiled QEMU would select an x86 CPU less than i686.
401291: 0f 44 cb cmove ecx,ebx
401294: eb e8 jmp 0x40127e
401296: 8d b4 26 00 00 00 00 lea esi,[esi+eiz*1+0x0]
40129d: 8d 76 00 lea esi,[esi+0x0]
race need apilib.dll
Download and install Arcade Toolbox Runtime
.
Ive choosen i386 also Pentium. It may be a bug on qemu. Bc a review of my build with the vm was capable of running dow games. Maybe it's something wrong than was fixed on master I guess. This qemu also runs slower than master
Ive choosen i386 also Pentium
Those aren't good enough. Do you have the option to choose something better? How about $ qemu-system-i386 -cpu ?
All the guest wrapper DLLs require at least an i686 supporting CMOV instructions. Please don't ask why, that's the x86 GNU GCC toolchain I use. Otherwise, you need to recompile all of them yourself.
How I get those? I dont know where to start
If you don't know where to start (to recompile the guest wrapper DLLs), won't it be easier for you just to select a better CPU to emulate from QEMU?
But I dont get why it's in the corner
But I dont get why it's in the corner
That's fine, because you are running QEMU in full-screen and the wglgears demo is an OpenGL full-screen app. Try to run QEMU in window and you will see how it work. For games, it is always going to be full-screen.
BTW, nice shot, nice to meet you.
Now need for speed runs, but on the corner!!
Unfortunately, that is how the host OpenGL works for now if QEMU is in fullscreen. If you run QEMU in windowed, then the window will be sized to fit the actual size of OpenGL rendering context. Usually, OpenGL games will have option to select the game resolution and this should be use to fill up the screen. The wglgears demo runs at 640x480. I meant to keep the MESA GL pass-through as simple as possible without adding any scaling/adjustment options for the rendering. It is all up to the games. And, I like playing games in windowed.
Well, it does 10 fps haha so.. not too much playable haha but it was a good experiment!! I will retry it on my rk3399 , panfrost provide 2.1 too
That was within expectation anyway. Without KVM, QEMU TCG may not have enough performance to run 3D games. Even though Linux on ARM does support KVM, but it cannot be used to accelerate foreign architecture instructions. Check out some of the performance figures for x86 KVM in action with QEMU: https://www.vogons.org/viewtopic.php?p=832278#p832278
Many thanks!
leave this result, Thanks @kjliew !!!
https://www.youtube.com/watch?v=H0IwylEIJ0Q&feature=youtu.be
Askmewho... can you write someware how did you fix step by step?
Change both two files definitions from above with
Then it compiles. Use at least pentium3/or similar and cirrus on qemu.
You can use gl4es to get desktop profile on other sbcs rather than rpi
Thanks mate.
Hello,
I'm not sure if I should create a new issue or continue with this one... because it is also related to the Raspberry Pi 4. But I'm using a 64-bit kernel (aarch64/arm64) and emulating Windows XP.
Mesa is installed and working:
glxinfo | grep "OpenGL version" OpenGL version string: 2.1 Mesa 20.1.2
I've used this patch: 10-qemu411-mesa-glide.patch
And edited these files to be used for the aarch64 architecture: qemu-3dfx/qemu-0/hw/3dfx/glide2x_impl.c qemu-3dfx/qemu-1/hw/mesa/mesagl_impl.c
Replaced:
#if defined(HOST_X86_64) && HOST_X86_64
with:
#if defined(HOST_AARCH64) && HOST_AARCH64
Then i've configured qemu qemu-4.1.1: (is there maybe a problem, e.g. that an important dependency is missing?)
./configure --target-list=i386-softmmu --enable-debug
Install prefix /usr/local
BIOS directory /usr/local/share/qemu
firmware path /usr/local/share/qemu-firmware
binary directory /usr/local/bin
library directory /usr/local/lib
module directory /usr/local/lib/qemu
libexec directory /usr/local/libexec
include directory /usr/local/include
config directory /usr/local/etc
local state directory /usr/local/var
Manual directory /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path /home/xxx/qemu/myqemu/qemu-3dfx/qemu-4.1.1
GIT binary git
GIT submodules
C compiler cc
Host C compiler cc
C++ compiler c++
Objective-C compiler cc
ARFLAGS rv
CFLAGS -g
QEMU_CFLAGS -I/usr/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt
-pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv
-std=gnu99 -Wexpansion-to-defined -Wendif-labels
-Wno-shift-negative-value -Wno-missing-include-dirs -Wempty-body
-Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition
-Wtype-limits -fstack-protector-strong -I/usr/include/p11-kit-1
-I/usr/include/libpng16 -I$(SRC_PATH)/capstone/include
LDFLAGS -Wl,--warn-common -g
QEMU_LDFLAGS -L$(BUILD_DIR)/dtc/libfdt
make make
install install
python python3 -B (3.8.3)
slirp support system
smbd /usr/sbin/smbd
module support no
host CPU aarch64
host big endian no
target list i386-softmmu
gprof enabled no
sparse enabled no
strip binaries no
profiler no
static build no
SDL support yes (2.0.12)
SDL image support no
GTK support yes (3.24.20)
GTK GL support yes
VTE support yes (0.60.3)
TLS priority NORMAL
GNUTLS support yes
libgcrypt no
nettle yes (3.6)
libtasn1 yes
PAM yes
iconv support yes
curses support yes
virgl support yes (0.8.2)
curl support yes
mingw32 support no
Audio drivers pa oss
Block whitelist (rw)
Block whitelist (ro)
VirtFS support yes
Multipath support no
VNC support yes
VNC SASL support yes
VNC JPEG support yes
VNC PNG support yes
xen support no
brlapi support yes
bluez support yes
Documentation no
PIE no
vde support yes
netmap support no
Linux AIO support yes
ATTR/XATTR support yes
Install blobs yes
KVM support yes
HAX support no
HVF support no
WHPX support no
TCG support yes
TCG debug enabled yes
TCG interpreter no
malloc trim support yes
RDMA support no
PVRDMA support no
fdt support git
membarrier no
preadv support yes
fdatasync yes
madvise yes
posix_madvise yes
posix_memalign yes
libcap-ng support yes
vhost-net support yes
vhost-crypto support yes
vhost-scsi support yes
vhost-vsock support yes
vhost-user support yes
Trace backends log
spice support no
rbd support no
xfsctl support yes
smartcard support yes
libusb yes
usb net redir yes
OpenGL support yes
OpenGL dmabufs yes
libiscsi support no
libnfs support yes
build guest agent yes
QGA VSS support no
QGA w32 disk info no
QGA MSI support no
seccomp support yes
coroutine backend ucontext
coroutine pool yes
debug stack usage no
mutex debugging yes
crypto afalg no
GlusterFS support no
gcov gcov
gcov enabled no
TPM support yes
libssh support yes
QOM debugging yes
Live block migration yes
lzo support yes
snappy support yes
bzip2 support yes
lzfse support no
NUMA host support yes
libxml2 yes
tcmalloc support no
jemalloc support no
avx2 optimization
replication support yes
VxHS block device no
bochs support yes
cloop support yes
dmg support yes
qcow v1 support yes
vdi support yes
vvfat support yes
qed support yes
parallels support yes
sheepdog support yes
capstone internal
docker no
libpmem support no
libudev yes
default devices yes
Building was successfully and faster as expected :)
After that I've started Windows XP with the default cpu, "-vga cirrus" and "-display sdl".
Then I've copied the file fxptl.sys into the directory "windows/system32/drivers". Copied glide.dll, glide2x.dll and glide3x.dll to "windows/system32". And executed instdrv.exe:
Driver installed
Driver started
fxLibInit OK
fxMapLinear OK, 0047f000
For testing I have executed the file "test04.exe".
But I've received the following error message:
The application failed to initialize properly (0xc0000142).
And the Host console outputs only:
glidept: DLL unloaded
Could you please help me to get qemu-3dfx running?
I think you just have to wait a while after Windows XP startup. This issue manifested in x86 build, too, but usually on slower systems and debug build. A good indicator is to enable QEMU networking -net nic,model=rtl8139 -net user
. After Windows XP displayed network connectivity, then you can try test04.exe.
Thank you for your reply.
I've rebuild qemu-3dfx without the debug option and added the -net nic,model=rtl8139 -net user
parameter.
After the boot up the network was quite fast active and I waited some more minutes but unfortunately without success.
@Askmewho posted:
new retry
ive compiled openglide
I haven't compiled any openglide stuff, is this maybe the problem?
Or should I use 01-qemu411-mesa.patch
instead of 10-qemu411-mesa-glide.patch
?
Here are some more additional infos. Host OS: Manjaro KDE Plasma (AARCH64 Version).
Guest OS: Fresh installed Windows XP SP3 (32-Bit Version). Only DirectX 9.0c, the 3 glide-dll's and fxptl.sys are installed... nothing more.
Thanks!
I haven't compiled any openglide stuff, is this maybe the problem?
Yes, you need OpenGlide at the host. If QEMU can't find host glide wrapper, then guest glide wrapper DLLs won't load at guest OS. If you don't want to compile OpenGlide, then you can't play 3Dfx Glide games with host glide wrapper. You can use Zeckensack's Glide wrapper on guest OS to translate Glide to OpenGL with some level of performance degradation.
Upstream OpenGlide is missing several fixes, experimental Glide3x and LFB fastpath for QEMU.
This project it's amazing, but you will not get better performance even with hw acceleration buddy. The qemu dynarec sucks. It will bottleneck everything.
You can use glide.cfg
to tweak some aspects of QEMU Glide pass-through. The defaults are tuned for x86 with KVM/WHPX acceleration. For ARM/AArch64 without KVM, changing LFB mode to "LfbHandler,1"
should be faster on TCG to save whole-screen copy of shared memory on minor LFB updates.
@Askmewho From the video, your OpenGlide could be a problem because it lacks the fix for proper LFB writemode handling. Otherwise, I think ARM/AArch64 at 2.0GHz should be able to deliver 30FPS for GLQuake and NFS2SE on QEMU TCG.
I've now compiled OpenGlide but the same error remains.
git clone https://github.com/voyageur/openglide.git
cd openglide
./bootstrap
./configure
make
sudo make install
Did I do something wrong or is something probably still missing? Or is it e.g. DirectX 9.0c, Cirrus, resolution, color depth, dpi...
Update: I've found a DosBox tutorial where the path to OpenGlide is specified. Do I also have to do something similar with Qemu?
cd dosbox
./autogen.sh
./configure CPPFLAGS="-I /usr/local/include/openglide/"
make
sudo make install
@Askmewho With SMP and the ARMv8 instruction sets, I might be able to squeeze out a bit more performance.
Hope you achieve better results. Just asking info, there are no wine alternatives to this to get glide hw acceleration on x86 linux?
There is no multithread official support for arm emulating x86 afaik. You need to try out other qemu forks than support that kind of approaches.
@WalkingDot If you still get the same error (0xc0000142), then it really meant that QEMU did not find libglide2x.so in the search path. Linux is tricky, I did not know about your distro if default lib.so path is /usr/lib or /usr/local/lib or /usr/lib/$arch/lib. Use LD_LIBRARY_PATH
on QEMU invocation to point to the host glide wrappers so that QEMU can find them. It is easier just to boot DOS in QEMU and run the DOS version of TEST04 to verify LD_LIBRARY_PATH in effect.
Wow... thank you so much for your help! I added the LD_LIBRARY_PATH and now it's working:
glidept: DLL loaded - glide2x.dll
trace: _grSstControl@4 called
trace: _grSstControl@4 called
trace: _grGlideGetVersion@4 called
glidept: grGlideGetVersion Glide 2.45 - OpenGLide 0.09rc9
trace: _grGlideInit@0 called
glidept: grSstWinOpen called, fmt 1 org 0 buf 2 aux 1 gLfb 0x00740000
glidept: LFB mode is Shared Memory (fast)
window 640x480
glidept: grSstWinClose called
glidept: grGlideShutdown called, fifo 0x00be data 0x0dae shm 0x00436b8 lfb 0xfb000000
glidept: GrState 1 VtxLayout 0
glidept: DLL unloaded
Next I have tried to start Diablo 2 LOD (1.14d) with the launch parameter -3dfx
.
But unfortunately this error message appears:
Error 1: Diablo II is unable to proceed. Unsupported graphics mode.
I've also tested Sven's GLIDE-wrapper, but I get an error, too:
Setpixelformat failed! OpenGL could not be activated. Please check your video driver.
That' s too bad :-(((
If I find Need for Speed, I would test it and report the "LfbHandler,1"
difference.
Need For Speed 2 SE demo is available at https://archive.org/details/NFS2SEA
Diablo 2 LOD (1.13d) works on Windows XP guest with Sven's GLIDE-wrapper within QEMU on x86 Linux. I stopped at v1.13d because this is the last version that still compatible with Win98SE. You need to put opengl32.dll
(MESAGL guest wrapper) and glide3x.dll
(Sven's Glide wrapper) into the game EXE folder. I think v1.14d should work equally well if you must play with this version.
Setpixelformat failed!
QEMU should have posted some logs on the console. Did you verify if wglgears.exe
worked from WinXP guest?
I'm sorry about all the noobish problems...
opengl32.dll
and wglgears.exe
were missing.
But I've found your wrpguest-mesagl-b7858ee.zip
on vogons and placed the opengl32.dll
into the game folder.
Now D2LOD, NFS2 and wglgears.exe
are working, but unfortunately they all have low fps.
I've created the glide.cfg
, added LfbHandler,1
withou the " " and placed it in:
/usr/local/share/quemu/
/usr/local/bin/
But I couldn't notice any difference, though.
Here I have a screenshot of Sven's GLIDE-Wrapper info/bench:
QEMU output console log will tell if "LfbHandler,1"
is in effect.
glidept: LFB mode is MMIO Handlers (slow)
As the log said, it only affects performance for Glide pass-through. When you used Sven's Glide wrapper, it was MESAGL pass-through with APIs wrapping at TCG (slow). You can do the same with OpenGlide if you built it as guest wrapper, but the performance is way better with OpenGlide as host wrapper with the guest DLL stubs simply passing along the APIs and API wrapping takes place at host CPU(fast). Unfortunately, OpenGlide does not work for Diablo II, the game will load and run (if you have the Glide3x patch), but rendering is flawed.
I don't have knowledge about OpenGL performance characteristics from ARM/AArch64, but I think wglgears
should be light enough to get 60FPS for any kind of accelerated OpenGL. GLQuake1 and NFS2SE played at near 30FPS on Intel Core m3-6Y30 at 1.5GHz on QEMU TCG with OpenGlide. While other factors such as OpenGL drivers maturity may be an advantage for x86, this is the performance level that I would expect from a similar clocked ARM/AArch64.
I'd guess it's Windows XP. It's too cpu hungry...
I intended to use 4 cores with smp
and accel tcg,thread=multi
... the game could use 1 core up to 100% and the remaining 3 cores are available for windows processes.
But if OpenGlide loads, the RPi4 get's memory errors and qemu crashes. So I've to use thread=single
and that's probably why even wglgears
runs poorly with slowdowns.
I will install Win 98SE in the next days and try again.
I'd guess it's Windows XP. It's too cpu hungry... I intended to use 4 cores with
smp
andaccel tcg,thread=multi
... the game could use 1 core up to 100% and the remaining 3 cores are available for windows processes. But if OpenGlide loads, the RPi4 get's memory errors and qemu crashes. So I've to usethread=single
and that's probably why evenwglgears
runs poorly with slowdowns.I will install Win 98SE in the next days and try again.
Bro im getting error on compiling in arm64 ,i have opened that issue plz look into it ,help if you can Also , what i have done to get 3dfx working on my device is
Qemu compilied with this option ./configure --target-list=x86_64-softmmu --enable-opengl --enable-virglrender --enable-sdl And i want direct3d enable in emulated windows xp Can you help me??
Hi!!! what i cant get it's how it would work without 3dfx (so, just gl).. I mean, we dont have mesa driver for windows 98.. how I could really use it?? What I need to install onto the guest windows 98??
after default 3dfx/mesa patch
after mesa only patch