VOGONS


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

Topic actions

  • This topic is locked. You cannot reply or edit posts.

Reply 520 of 619, by mr.cat

User metadata
Rank Member
Rank
Member

Hi guys, great to see some action in this thread 😀

Personally, I'm not super interested in seeing benchmarks against PCem, because I know what to expect from both. But here's the thing: Not everyone does.
Maybe getting the word out there would also help getting some eyeballs on qemu in general.
OTOH I don't know if this confrontational approach is a very good way to reach that goal. On this thread, you're preaching to the choir for the most part, and on the other threads it's easy to irk ppl off by rubbing qemu to their face...
Getting some user-friendliness in first also would not be a bad thing. Stating the obvious here but right now, the barrier of entry to qemu-3dfx is pretty damn high.
(This situation isn't wholly unique to qemu-3dfx. Those qemu vfio setups need a similar kind of dedication to get up and running. They're actually even worse, because you need specific hw.)

There's another thing that springs to mind: Maybe it would be time to do some restructuring?
This thread has been going for quite a while and it's getting pretty hard to read for any newcomers (I should know, I've read it 😀

Let's see, in recent times there's at least:
- Configuring Win98 guest for qemu-3dfx use
- Win9x 2d driver for virtual machine guest use
- QEMU(-3dfx) and PCem performance considerations, with benchmarks

Before that, there were long stretches dedicated to simply getting the thing compile.

Last edited by mr.cat on 2021-01-21, 00:42. Edited 3 times in total.

Reply 521 of 619, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie

It is OpenGL for UT2003. Where have you been in the last 2 years?

I never saw this thread, i could overlook it, but maybe it was even mentioned in this thread, it would be nice link al related threads and post in 1st post, they really are in couple of other topic.. That is part which i really dont understand, you are doing promotion this way, but in otherhand you dont want to promote it by releasing complete builds, to make it much easier to use.. to get much more users / fame / attention.

I don't have a great desktop CPU to show off the better part of PCem. I halted desktop upgrade indefinitely. My best CPU is on thin & light laptop, the Ryzen 2500U, but PCem is hopeless on any mobile CPU

Im not using laptops, simply because of headaches from their noise, unless they are fanless as your 15W Ryzen could be.. but after that they were usually quite slow, especially at GPU side.. and when i really work, i need lots of windows and monitors real estate, so when i using laptops, i have it on stand and 2 external monitors beside, external mouse and keyboard, so its desktop like regardless, only noisier and transportable. During travelling, when i get free plug in train or on business trip in hotel (but again typically connected to TV screen because simply bending in front of a laptop without some stand is far from ergonomic), it make sense, but other in all other circumstances, handheld style gaming device is better and at hotel could be often connected to TV too.
I dont thing that Ryzen 2500U is something too much slow, if Geekbench score is not lying, its ~ half of not so old Core i7 7700K performance, at least for the while in turbo, before throttling etc.

I dont thing that people are shy to post PCem numbers, i thing that they dont need to, because you can simply google, results of real HW which is emulated, on old site. If is not emulated at full speed, it make no sense to emulated such HW and you need to emulate something slower, which you can run at full speed. Its like resolution and details in games.
Regardless, i would like to see comparison of these on same HW.. i dont mind if PCem framerate would be 5 FPS, unplayable etc, this is reality. I even would make such benchmark, if would have working build of both.. I added some virtualization results to my Dos Fast CPU + GPU benchmarking thread (sheet), there is even some Qemu, but because of Qemu bug, i never was able to run 640x480 or higher resolution: https://docs.google.com/spreadsheets/d/1QPf4V … t#gid=919349920
Im not telling that PCem has not bugs, for example its loading Q2Dos for minute or two, there has to be something wrong with disk subsystem, i did some benchmarking and i got realy strange results, maybe it is fixed in new version, maybe not.. I have to check their forum.

Perhaps I was so wrong and those games are indeed playable with Core i9 9900K, all one needs is 30fps, anything more is superficial.

30 FPS means playable, what is big thing, yeah its console quality, its Doom quality (35FPS lock).. i dont mind more, that is why i have nice 144 Hz monitor, but i also like sit and play and not sit and trying to make game whole setup running for very long time.

I think we are there now, it is no longer just a dream with QEMU, and only with QEMU for now

Maybe, or probably, but how many people can enjoy it? People have problems to build it, its not unstreamed in QEMU, there is lots of quite stranger and more alien thing, unstreamed for while. When late its not easy to setup it right for Glide.. and if im not wrong anything with OpenGL is not public.. So you are there, we are not, few of us is there maybe with Glide. BTW made someone here some compatibility matrix, what is working and what is not?

I dont thing that you need to make lots ofvideos yourself, you only need to make package easily to use to users, i sure that somebody will make some video and compatibility list.

I dont thing that idea of virtualization of Win98 machine, is not welcome - its not Amiga overpriced HW old problem or some you have to use real HW etc.. Such people would ignore these thread, whole virtualization stuff, Dosbox etc.
I would say that is communication problem, simple to use things are usually successful and vice versa.. and they could be very complex inside, which should remain for most of users blackbox.
Geforce 6 line still has official Windows 98 support, with physical Win98 you get up to X79 board with still good enough for new games 6 six core + HT Core i7 for gaming and native PCI sound card, which is working in Dual boot in Dos / Win98.. if dont need Dos Sound you can get even higher, i dunno where is the limit, even Z170,Z370 is able to run Win98 fine... I have whole thread about it:
X58/i865/V880 - Yamaha7x4/AureaV1/2 pure Dos7.1- compatibility list/research/ ultim. drivers configs, WIP- gurus needed

and there are clever people which would be probably able to make some bridge to make Dos sound working with every MB with PCI slot..
PCie-to PCI, PCI to ISA, # of slots multipliers - bridges, risers, backplanes, research, especially for DOS, WIP.

As your pushing on SW side, they are pushing on HW side. SW site has to ultimately Win, but we are not there yet, because of bugs and missing features.. Virtualbox and Vmware, had not 3D support in Dos / Win9x and good Dos sound.. and already wrote lots about Qemu and linked and reported couple of annoying Dos bugs and 3D is very hard to get working and PCem is slow - but still the best.

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 522 of 619, by OSH

User metadata
Rank Member
Rank
Member
kjliew wrote on 2021-01-09, 21:29:
To successfully accelerate Win98/ME guest with KVM/WHPX, there are several tricky parts. 1. You can't use cirrus-vga or just pla […]
Show full quote
mr.cat wrote on 2021-01-09, 20:06:

The better drivers (bearwindows or vmware ones from 8.3.19 tools iso) don't seem to work, as you said.
Also, with -enable-kvm I consistently got a black screen, so had to ditch that too. But this might be dependant on host hw.

To successfully accelerate Win98/ME guest with KVM/WHPX, there are several tricky parts.
1. You can't use cirrus-vga or just plain VGA (planar I/O access) with KVM/WHPX. You have to use VBEMP 9x or VMware SVGA and I recommend the former. The main blocker to get around for starting from scratch is to stay with TCG (slow) until the proper display driver is installed to obtain 256-color or 16-bit color desktop. Once you got there, you are in LFB mode. Then on next boot, you can enable KVM after step #2 (IMPORTANT)
2. Disable Win98 startup logo. Edit MSDOS.SYS and place "Logo=0" in the [Options].

Step #1 is very painful, so once it is done, any sane mind would not want to repeat that. So please back it up with an imaging tool. I use fsarchiver with Linux-based rescue LiveCD. QEMU KVM can boot up the LiveCD and re-image Win98 in 5 mins (compared to 35mins up to an hour for setup #1) on a reasonably fast SSD storage.

In any circumstances that you were forced into Win98 Safe Mode, KVM/WHPX would just crash. So just keep in mind to stay with TCG if Safe Mode was really needed. Otherwise, it is significantly faster to restore the installation from image.

Hey, did I understood this right? My QEMU finally works with this 3dfx emulation without these steps, so they are necessary? And second question: How did you set up QEMU to works with XvT?

Reply 523 of 619, by mr.cat

User metadata
Rank Member
Rank
Member
OSH wrote on 2021-01-20, 23:36:
kjliew wrote on 2021-01-09, 21:29:
To successfully accelerate Win98/ME guest with KVM/WHPX, there are several tricky parts. 1. You can't use cirrus-vga or just pla […]
Show full quote
mr.cat wrote on 2021-01-09, 20:06:

The better drivers (bearwindows or vmware ones from 8.3.19 tools iso) don't seem to work, as you said.
Also, with -enable-kvm I consistently got a black screen, so had to ditch that too. But this might be dependant on host hw.

To successfully accelerate Win98/ME guest with KVM/WHPX, there are several tricky parts.
1. You can't use cirrus-vga or just plain VGA (planar I/O access) with KVM/WHPX. You have to use VBEMP 9x or VMware SVGA and I recommend the former. The main blocker to get around for starting from scratch is to stay with TCG (slow) until the proper display driver is installed to obtain 256-color or 16-bit color desktop. Once you got there, you are in LFB mode. Then on next boot, you can enable KVM after step #2 (IMPORTANT)
2. Disable Win98 startup logo. Edit MSDOS.SYS and place "Logo=0" in the [Options].

Step #1 is very painful, so once it is done, any sane mind would not want to repeat that. So please back it up with an imaging tool. I use fsarchiver with Linux-based rescue LiveCD. QEMU KVM can boot up the LiveCD and re-image Win98 in 5 mins (compared to 35mins up to an hour for setup #1) on a reasonably fast SSD storage.

In any circumstances that you were forced into Win98 Safe Mode, KVM/WHPX would just crash. So just keep in mind to stay with TCG if Safe Mode was really needed. Otherwise, it is significantly faster to restore the installation from image.

Hey, did I understood this right? My QEMU finally works with this 3dfx emulation without these steps, so they are necessary? And second question: How did you set up QEMU to works with XvT?

Hi OSH! Yes it's a good idea to have ACPI and VBEBM in the guest.
A nice thing about these virtual machines is that you can test all kinds of setups and get back to where you started easily, if needed.
(That is a sweet sweet luxury we didn't have in the 90's!)

Are you using -enable-kvm to launch qemu-3dfx?
My understanding is that the cirrus drivers know nothing of these hw virtualization features, and so they won't really work with KVM or WHPX. kjliew explains it here.
The keywords there being, *host accelerated*.

Reply 524 of 619, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Geforce 6 lines do not have Win9x driver support. I go by official source. Otherwise, I would have kept my Nforce 630i/GeForce 7150 IGP motherboard for old Windows games with Core 2. If you want to hack the drivers, then it is your choice. I stand corrected.
Edit: Actually Geforce 6 lines do have official driver. I kept forgetting that IGP for Intel CPUs is GeForce 7 series

By the way, I do hope someone can leak the unofficial drivers of i910/i915 IGP that fully work on Win98. I knew they exist. 😜

Yes, I agree. If one cannot get QEMU to work, then PCem is still the best you can have for now.

Frankly, getting things to work with awkward ways is just not my cup of tea, such as booting WinXP on Ryzens, stubbing DOSBox with HXDOS extender to get sound for DOS games under real DOS, putting an ISA sound card over PCI over PCI-e bridge etc. just to name a few. There are folks who will follow 30 steps guide in PC game wiki to get the games work on Windows 10, but not me, that's just me. I have no means to offend anyone, I am sorry if I did it unintentionally.

Reply 525 of 619, by RayeR

User metadata
Rank Member
Rank
Member

I wonder a bit that any of folowers in this thread who make QEMU compiled and working too (is here someone else than kjliew himself? I'm lost in thread, it's quite long and I didn't remember what was on begining 2 years ago) didn't write some article on homepage or blog with some step by step how to compile and put all things together + upload own compiled binaries for those who doesn't have enough time to waste on it (what was once done before) and link it in 1st page here... 😀

BTW someone else may like to try awkward ways to run old systems native on new HW, not everything can be virtualized at full speed/functionality, there are some HW limits like huge overhead on VMEXIT calls...

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 4GB DDR3, 128GB SSD, GTX670(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo

Reply 526 of 619, by mr.cat

User metadata
Rank Member
Rank
Member
RayeR wrote on 2021-01-21, 04:30:

I wonder a bit that any of folowers in this thread who make QEMU compiled and working too (is here someone else than kjliew himself?

🙋
Yep. Surely I'm not the only one? Here's the recipe I used for compilation back in December:
Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

For guest configuration the necessary steps can be found in the later posts this thread (mostly applies to Win9x though - Win2k/XP wasn't discussed much)
That was the hard part, at least for me...I only suffered WinME briefly when it came out. I was already going into Linux direction at that point, and never installed Win9x/ME.
Note that my testing hasn't been very extensive. Also there haven't been much talk about WineD3D tricks that may be necessary for Direct3D apps.

RayeR wrote on 2021-01-21, 04:30:

BTW someone else may like to try awkward ways to run old systems native on new HW, not everything can be virtualized at full speed/functionality, there are some HW limits like huge overhead on VMEXIT calls...

Its good to have different approaches. The end user can then decide for themselves what's best for them.
And virtualization is a somewhat moving target too. There are some future hw trends emerging like FPGA's, a possible move to different architectures etc.
But this API wrapping bypasses much of what happens at the hardware level, so it's quite a nice way to future-proofing.

Reply 527 of 619, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
mr.cat wrote on 2021-01-21, 05:12:

🙋
Yep. Surely I'm not the only one? Here's the recipe I used for compilation back in December:
Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

🤫 (whispering ... ) you might be rubbing qemu to someone's face ... 🤣 🤣

Thanks to the disease spread by Facebook, Instagram etc. these days. 🤣

Reply 528 of 619, by mr.cat

User metadata
Rank Member
Rank
Member
kjliew wrote on 2021-01-21, 06:01:
mr.cat wrote on 2021-01-21, 05:12:

🙋
Yep. Surely I'm not the only one? Here's the recipe I used for compilation back in December:
Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

🤫 (whispering ... ) you might be rubbing qemu to someone's face ... 🤣 🤣

Thanks to the disease spread by Facebook, Instagram etc. these days. 🤣

Whoops! Gotta be mindful of that before we get queries for "if you got qemu rubbed to your face, report back here" 🤣
Anyways, my 0.02 eurocents to this is that "if you build it they come" doesn't really work, until it's easy enough for an average Joe.
Then you'll start to see the attention this project deserves...

Reply 529 of 619, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie
kjliew wrote on 2021-01-21, 01:57:

Frankly, getting things to work with awkward ways is just not my cup of tea..

It really depends if there is other way, often isnt but in my case it is. Just distribute complete Qemu build at least for Windows with some basic disk image and qemu starting line, as RobertMo once did, its not too much work, main problem is building.

I wonder a bit that any of folowers in this thread who make QEMU compiled and working too?

I once build it right, but it was 4.xx, with 5 or 4.1, 4.2 not sure, i wasnt so lucky, especially with manualy editing files to make sound patch working. There are also some builds too download from RobertMo, but even with minimal Dos disk image, but there was some Dos related problem, not working EMS, Himem or something like that in Dos, for Windows 98 it was working, but not without acceleration, when i tried to make MS VM acceleration working i always failed, crash after user login.

BTW even Qemu pass through is not ideal for Dos, i already linked errors with virtual machine errors, but also real PCI sound card passthrough is not working with DOS.

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 530 of 619, by RayeR

User metadata
Rank Member
Rank
Member
mr.cat wrote on 2021-01-21, 05:12:

🙋 Yep. Surely I'm not the only one? Here's the recipe I used for compilation back in December:
Re: QEMU 3Dfx Glide Pass-Through (WHPX/KVM works!!!)

Thanks, yeah I was intentionally a bit over... this, I know at least ruthan and you was playing with it with some success too.
You already mentioned that it become hard to get in for newcomers. So any reason why to not upload a binary and some better documentation than scattered thread (yeah 27 pages is still nothing compared to some cool threads on Win-raid and MSFN wit 400+ pages)? I understands why bins are not much distributed for Linux as there are many differences across the distros, kernels etc. but why not for Windows? The disk image wouldn't be problem, just would nice to have compiled guest files.
I'm personally not enough motivated to go in compiling (rather just curious about reached performance and rsults and have a lot of work on own projects) as I'm primary aimed on DOS sound emulation and some older Win D3D/GL games still can run native...

mr.cat wrote on 2021-01-21, 05:12:

And virtualization is a somewhat moving target too. There are some future hw trends emerging like FPGA's, a possible move to different architectures etc.

Don't expect miracles from FPGAs, they had several speed limitations compared to "hardwired"silicon and top models are quite expansive. Currently it's good way to emulate various 8bits, Amiga, Consoles but not a Pentium II PC with 3Dfx...
Doing API passthrough is of course best thing to do, for systems using APIs but DOS stuff handle HW directly and then it's much slower for virtualization. Except as ruthan mentioned passing the whole HW on PCI bus but not all systems supports VT-d I/O.

BTW I recently tried DosBox-X with stubbed minilinux booted from dos within 1s and got quite decent performance 42FPS in Q1 1024x768 (and with sound support).

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 4GB DDR3, 128GB SSD, GTX670(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo

Reply 531 of 619, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Updated 1st post.

OpenGlide fork optimized for QEMU is now available. This is mostly meant for Linux folks, especially ARM SBC/RPi4 community where 1st-party Glide pass-through can be faster than 3rd-party Glide from Windows guest on top of MESAGL pass-through. For Linux x86/x64 with KVM, no big deal on either ways of pass-through from my testing, so just pick whichever is the most compatible for target games. OpenGlide can be used in either Host or Guest depending on compilation. Native compilation is used for Host and cross-compilation (or native compilation in VM) is used for Guest.

If one is building this for ARM, then it is recommended to use recent GCC compiler with SIMD auto-vectorizing optimization. The x86-64 enjoys at least SSE2 by default and pixel operations are automatically vectorized with SIMD instructions with "-O2" or higher.

Reply 532 of 619, by mr.cat

User metadata
Rank Member
Rank
Member
RayeR wrote on 2021-01-22, 05:22:
mr.cat wrote on 2021-01-21, 05:12:

And virtualization is a somewhat moving target too. There are some future hw trends emerging like FPGA's, a possible move to different architectures etc.

Don't expect miracles from FPGAs, they had several speed limitations compared to "hardwired"silicon and top models are quite expansive. Currently it's good way to emulate various 8bits, Amiga, Consoles but not a Pentium II PC with 3Dfx...

Actually I was thinking about Intel purchasing Altera and more recently, AMD buying Xilinx. It's one way of lowering the power consumption in the Cloud I suppose, but it's possible that FPGAs will have a bigger role in the future.
The point was that we don't know what the future hw will look like. It looks there is already some arm work underway..

As for docs & binaries, my guess is that there is a lack of time and/or interest. This is an enthusiast project and not on the list to gain any Red Hat funding, after all.
If you've done any coding you know how time consuming that is..and for most folks documentation is just boring as hell, so it's done last.

Reply 533 of 619, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie

If someone will succeed to build Qemu 5.2 3Dfx for windows with help of new instructions, pleas share it.. ideally with all resource Qemu file needed to run it, because if remember correctly its other step which is needed, andwhich is not described and its not as simple as it could seem.

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 534 of 619, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie

Ok, ok.. i did that mistake again, that i tried it by myself..
I still dont thing that is right way to make user compile it, but there some notes:
- without some msys2 setup tutorial are these notes (with all needed packages), i dont want to say useless, but lest say far from complete..
- it would be nice somehow enhance mkdir command, to overwrite directories, if already exist to not force user to have to delete them // small thing but, if you are trying to create some tutorials and installation package for more 10+ users, from experience every details count and in each step every user can halt
- during files extraction there is lots of errors because of Linux symlinks, but would be good to note to Windows users, that these errors are fine..
- i would be nice to point how to select proper target, because i did it long time ago, so i got all of them..
- i had some setup from the past and executed last step:
../qemu-5.2.0/configure && make
i got: ERROR: Cannot find Ninja
because im not more newbie with it, i know that i need download some package and it has some build in linux package system, so i googled:
pacman -S mingw-w64-x86_64-ninja
- i ran it again, it compiled for while, but ended with:
Found ninja-1.10.0 at C:/Progamy/msys64/mingw64/bin/ninja.exe
WARNING: Could not create compilation database.
/mingw64/bin/ninja build.ninja && touch build.ninja.stamp
ninja: error: build.ninja:25741: multiple rules generate ../qemu-5.2.0/default-configs/devices/aarch64-softmmu.mak [-w dupbuild=err]

make[1]: *** No rule to make target 'multiboot.bin', needed by 'all'. Stop.
make: *** [Makefile:206: pc-bios/optionrom/all] Error 2

- Im also not know, if this build would be good enough for WHPUX, any other Windows acceleration possiblity or not.

There are some details:

Spoiler

ln: failed to create symbolic link 'aarch64-softmmu/qemu-system-aarch64': No such file or directory
ln: failed to create symbolic link 'alpha-softmmu/qemu-system-alpha': No such file or directory
ln: failed to create symbolic link 'arm-softmmu/qemu-system-arm': No such file or directory
ln: failed to create symbolic link 'avr-softmmu/qemu-system-avr': No such file or directory
ln: failed to create symbolic link 'cris-softmmu/qemu-system-cris': No such file or directory
ln: failed to create symbolic link 'hppa-softmmu/qemu-system-hppa': No such file or directory
ln: failed to create symbolic link 'i386-softmmu/qemu-system-i386': No such file or directory
ln: failed to create symbolic link 'm68k-softmmu/qemu-system-m68k': No such file or directory
ln: failed to create symbolic link 'microblaze-softmmu/qemu-system-microblaze': No such file or directory
ln: failed to create symbolic link 'microblazeel-softmmu/qemu-system-microblazeel': No such file or directory
ln: failed to create symbolic link 'mips-softmmu/qemu-system-mips': No such file or directory
ln: failed to create symbolic link 'mips64-softmmu/qemu-system-mips64': No such file or directory
ln: failed to create symbolic link 'mips64el-softmmu/qemu-system-mips64el': No such file or directory
ln: failed to create symbolic link 'mipsel-softmmu/qemu-system-mipsel': No such file or directory
ln: failed to create symbolic link 'moxie-softmmu/qemu-system-moxie': No such file or directory
ln: failed to create symbolic link 'nios2-softmmu/qemu-system-nios2': No such file or directory
ln: failed to create symbolic link 'or1k-softmmu/qemu-system-or1k': No such file or directory
ln: failed to create symbolic link 'ppc-softmmu/qemu-system-ppc': No such file or directory
ln: failed to create symbolic link 'ppc64-softmmu/qemu-system-ppc64': No such file or directory
ln: failed to create symbolic link 'riscv32-softmmu/qemu-system-riscv32': No such file or directory
ln: failed to create symbolic link 'riscv64-softmmu/qemu-system-riscv64': No such file or directory
ln: failed to create symbolic link 'rx-softmmu/qemu-system-rx': No such file or directory
ln: failed to create symbolic link 's390x-softmmu/qemu-system-s390x': No such file or directory
ln: failed to create symbolic link 'sh4-softmmu/qemu-system-sh4': No such file or directory
ln: failed to create symbolic link 'sh4eb-softmmu/qemu-system-sh4eb': No such file or directory
ln: failed to create symbolic link 'sparc-softmmu/qemu-system-sparc': No such file or directory
ln: failed to create symbolic link 'sparc64-softmmu/qemu-system-sparc64': No such file or directory
ln: failed to create symbolic link 'tricore-softmmu/qemu-system-tricore': No such file or directory
ln: failed to create symbolic link 'x86_64-softmmu/qemu-system-x86_64': No such file or directory
ln: failed to create symbolic link 'xtensa-softmmu/qemu-system-xtensa': No such file or directory
ln: failed to create symbolic link 'xtensaeb-softmmu/qemu-system-xtensaeb': No such file or directory
cross containers no

NOTE: guest cross-compilers enabled: cc
The Meson build system
Version: 0.55.3
Source dir: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/qemu-5.2.0
Build dir: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build
Build type: native build
Using 'PKG_CONFIG_PATH' from environment with value: 'C:\\Progamy\\msys64\\mingw64\\lib\\pkgconfig;C:\\Progamy\\msys64\\mingw64\\share\\pkgconfig'
Using 'PKG_CONFIG_PATH' from environment with value: 'C:\\Progamy\\msys64\\mingw64\\lib\\pkgconfig;C:\\Progamy\\msys64\\mingw64\\share\\pkgconfig'
Project name: qemu
Project version: 5.2.0
C compiler for the host machine: cc (gcc 7.3.0 "cc (Rev2, Built by MSYS2 project) 7.3.0")
C linker for the host machine: cc ld.bfd 2.30
Host machine cpu family: x86_64
Host machine cpu: x86_64
../qemu-5.2.0/meson.build:10: WARNING: Module unstable-keyval has no backwards or forwards compatibility and might not exist in future releases.
Program sh found: YES
Program python3 found: YES (C:/Progamy/msys64/mingw64/bin/python3.exe)
C++ compiler for the host machine: c++ (gcc 7.3.0 "c++ (Rev2, Built by MSYS2 project) 7.3.0")
C++ linker for the host machine: c++ ld.bfd 2.30
Program cgcc found: NO
Library m found: YES
Library util found: NO
Library ws2_32 found: YES
Library winmm found: YES
Windows resource compiler: GNU windres (GNU Binutils) 2.30
Has header "WinHvPlatform.h" : YES
Has header "WinHvEmulation.h" : YES
Run-time dependency appleframeworks found: NO (tried framework)
Found pkg-config: C:\Progamy\msys64\mingw64\bin/pkg-config.EXE (0.29.2)
Using 'PKG_CONFIG_PATH' from environment with value: 'C:\\Progamy\\msys64\\mingw64\\lib\\pkgconfig;C:\\Progamy\\msys64\\mingw64\\share\\pkgconfig'
Run-time dependency pixman-1 found: YES 0.34.0
Library aio found: NO
Using 'PKG_CONFIG_PATH' from environment with value: 'C:\\Progamy\\msys64\\mingw64\\lib\\pkgconfig;C:\\Progamy\\msys64\\mingw64\\share\\pkgconfig'
Run-time dependency zlib found: YES 1.2.11
Run-time dependency xkbcommon found: NO (tried pkgconfig)
Library rt found: NO
Run-time dependency ncurses found: NO (tried pkgconfig)
Using 'PKG_CONFIG_PATH' from environment with value: 'C:\\Progamy\\msys64\\mingw64\\lib\\pkgconfig;C:\\Progamy\\msys64\\mingw64\\share\\pkgconfig'
Run-time dependency ncursesw found: YES 6.1.20180407
Using 'PKG_CONFIG_PATH' from environment with value: 'C:\\Progamy\\msys64\\mingw64\\lib\\pkgconfig;C:\\Progamy\\msys64\\mingw64\\share\\pkgconfig'
Run-time dependency sdl2 found: YES 2.0.12
Using 'PKG_CONFIG_PATH' from environment with value: 'C:\\Progamy\\msys64\\mingw64\\lib\\pkgconfig;C:\\Progamy\\msys64\\mingw64\\share\\pkgconfig'
Run-time dependency sdl2_image found: YES 2.0.5
Using 'PKG_CONFIG_PATH' from environment with value: 'C:\\Progamy\\msys64\\mingw64\\lib\\pkgconfig;C:\\Progamy\\msys64\\mingw64\\share\\pkgconfig'
Run-time dependency libpng found: YES 1.6.34
Using 'PKG_CONFIG_PATH' from environment with value: 'C:\\Progamy\\msys64\\mingw64\\lib\\pkgconfig;C:\\Progamy\\msys64\\mingw64\\share\\pkgconfig'
Run-time dependency libjpeg found: YES 1.5.3
Has header "sasl/sasl.h" : NO
Run-time dependency u2f-emu found: NO (tried pkgconfig)
Run-time dependency libkeyutils found: NO (tried pkgconfig)
Checking for function "gettid" : NO
Has header "sys/ioccom.h" : NO
Program scripts/minikconf.py found: YES
Configuring aarch64-softmmu-config-target.h using configuration
Configuring aarch64-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/aarch64-softmmu-config-devices.mak.d
Configuring aarch64-softmmu-config-devices.h using configuration
Configuring alpha-softmmu-config-target.h using configuration
Configuring alpha-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/alpha-softmmu-config-devices.mak.d
Configuring alpha-softmmu-config-devices.h using configuration
Configuring arm-softmmu-config-target.h using configuration
Configuring arm-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/arm-softmmu-config-devices.mak.d
Configuring arm-softmmu-config-devices.h using configuration
Configuring avr-softmmu-config-target.h using configuration
Configuring avr-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/avr-softmmu-config-devices.mak.d
Configuring avr-softmmu-config-devices.h using configuration
Configuring cris-softmmu-config-target.h using configuration
Configuring cris-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/cris-softmmu-config-devices.mak.d
Configuring cris-softmmu-config-devices.h using configuration
Configuring hppa-softmmu-config-target.h using configuration
Configuring hppa-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/hppa-softmmu-config-devices.mak.d
Configuring hppa-softmmu-config-devices.h using configuration
Configuring i386-softmmu-config-target.h using configuration
Configuring i386-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/i386-softmmu-config-devices.mak.d
Configuring i386-softmmu-config-devices.h using configuration
Configuring m68k-softmmu-config-target.h using configuration
Configuring m68k-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/m68k-softmmu-config-devices.mak.d
Configuring m68k-softmmu-config-devices.h using configuration
Configuring microblaze-softmmu-config-target.h using configuration
Configuring microblaze-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/microblaze-softmmu-config-devices.mak.d
Configuring microblaze-softmmu-config-devices.h using configuration
Configuring microblazeel-softmmu-config-target.h using configuration
Configuring microblazeel-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/microblazeel-softmmu-config-devices.mak.d
Configuring microblazeel-softmmu-config-devices.h using configuration
Configuring mips-softmmu-config-target.h using configuration
Configuring mips-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/mips-softmmu-config-devices.mak.d
Configuring mips-softmmu-config-devices.h using configuration
Configuring mips64-softmmu-config-target.h using configuration
Configuring mips64-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/mips64-softmmu-config-devices.mak.d
Configuring mips64-softmmu-config-devices.h using configuration
Configuring mips64el-softmmu-config-target.h using configuration
Configuring mips64el-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/mips64el-softmmu-config-devices.mak.d
Configuring mips64el-softmmu-config-devices.h using configuration
Configuring mipsel-softmmu-config-target.h using configuration
Configuring mipsel-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/mipsel-softmmu-config-devices.mak.d
Configuring mipsel-softmmu-config-devices.h using configuration
Configuring moxie-softmmu-config-target.h using configuration
Configuring moxie-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/moxie-softmmu-config-devices.mak.d
Configuring moxie-softmmu-config-devices.h using configuration
Configuring nios2-softmmu-config-target.h using configuration
Configuring nios2-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/nios2-softmmu-config-devices.mak.d
Configuring nios2-softmmu-config-devices.h using configuration
Configuring or1k-softmmu-config-target.h using configuration
Configuring or1k-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/or1k-softmmu-config-devices.mak.d
Configuring or1k-softmmu-config-devices.h using configuration
Configuring ppc-softmmu-config-target.h using configuration
Configuring ppc-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/ppc-softmmu-config-devices.mak.d
Configuring ppc-softmmu-config-devices.h using configuration
Configuring ppc64-softmmu-config-target.h using configuration
Configuring ppc64-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/ppc64-softmmu-config-devices.mak.d
Configuring ppc64-softmmu-config-devices.h using configuration
Configuring riscv32-softmmu-config-target.h using configuration
Configuring riscv32-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/riscv32-softmmu-config-devices.mak.d
Configuring riscv32-softmmu-config-devices.h using configuration
Configuring riscv64-softmmu-config-target.h using configuration
Configuring riscv64-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/riscv64-softmmu-config-devices.mak.d
Configuring riscv64-softmmu-config-devices.h using configuration
Configuring rx-softmmu-config-target.h using configuration
Configuring rx-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/rx-softmmu-config-devices.mak.d
Configuring rx-softmmu-config-devices.h using configuration
Configuring s390x-softmmu-config-target.h using configuration
Configuring s390x-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/s390x-softmmu-config-devices.mak.d
Configuring s390x-softmmu-config-devices.h using configuration
Configuring sh4-softmmu-config-target.h using configuration
Configuring sh4-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/sh4-softmmu-config-devices.mak.d
Configuring sh4-softmmu-config-devices.h using configuration
Configuring sh4eb-softmmu-config-target.h using configuration
Configuring sh4eb-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/sh4eb-softmmu-config-devices.mak.d
Configuring sh4eb-softmmu-config-devices.h using configuration
Configuring sparc-softmmu-config-target.h using configuration
Configuring sparc-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/sparc-softmmu-config-devices.mak.d
Configuring sparc-softmmu-config-devices.h using configuration
Configuring sparc64-softmmu-config-target.h using configuration
Configuring sparc64-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/sparc64-softmmu-config-devices.mak.d
Configuring sparc64-softmmu-config-devices.h using configuration
Configuring tricore-softmmu-config-target.h using configuration
Configuring tricore-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/tricore-softmmu-config-devices.mak.d
Configuring tricore-softmmu-config-devices.h using configuration
Configuring x86_64-softmmu-config-target.h using configuration
Configuring x86_64-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/x86_64-softmmu-config-devices.mak.d
Configuring x86_64-softmmu-config-devices.h using configuration
Configuring xtensa-softmmu-config-target.h using configuration
Configuring xtensa-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/xtensa-softmmu-config-devices.mak.d
Configuring xtensa-softmmu-config-devices.h using configuration
Configuring xtensaeb-softmmu-config-target.h using configuration
Configuring xtensaeb-softmmu-config-devices.mak with command
Reading depfile: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build/meson-private/xtensaeb-softmmu-config-devices.mak.d
Configuring xtensaeb-softmmu-config-devices.h using configuration
Run-time dependency capstone found: NO (tried pkgconfig)
Configuring capstone-defs.h using configuration
Run-time dependency slirp found: NO (tried pkgconfig)
Library iphlpapi found: YES
Configuring libslirp-version.h using configuration
Library fdt found: NO
Configuring config-host.h using configuration
Program scripts/hxtool found: YES
Program scripts/shaderinclude.pl found: YES
Program scripts/qapi-gen.py found: YES
Program scripts/qemu-version.sh found: YES
Run-time dependency threads found: YES
Program keycodemapdb/tools/keymap-gen found: YES
Program scripts/decodetree.py found: YES
Program ../scripts/modules/module_block.py found: YES
Program ../scripts/block-coroutine-wrapper.py found: YES
Program nm found: YES
Program scripts/undefsym.py found: YES
Program scripts/feature_to_c.sh found: YES
Program wixl found: NO
Program bzip2 found: YES
Configuring 50-edk2-i386-secure.json using configuration
Configuring 50-edk2-x86_64-secure.json using configuration
Configuring 60-edk2-aarch64.json using configuration
Configuring 60-edk2-arm.json using configuration
Configuring 60-edk2-i386.json using configuration
Configuring 60-edk2-x86_64.json using configuration
Program qemu-keymap found: NO
Program sphinx-build-3 sphinx-build found: NO
Program python3 found: YES (C:/Progamy/msys64/mingw64/bin/python3.exe)
Program diff found: YES
Program initrd-stress.sh found: YES
Program scripts/nsis.py found: YES
Build targets in project: 457

qemu 5.2.0

Install prefix: C:/Progamy/msys64/qemu
BIOS directory: ./
firmware path: C:/Progamy/msys64/qemu/qemu-firmware
binary directory: .
library directory: lib
module directory: lib/
libexec directory: libexec
include directory: include
config directory: C:/Progamy/msys64/qemu
local state directory: queried at runtime
Doc directory: C:/Progamy/msys64/qemu
Build directory: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/build
Source path: C:/Progamy/msys64/home/RuThaN_/myqemu/qemu-3dfx/qemu-5.2.0
GIT binary: git
GIT submodules:
C compiler: cc
Host C compiler: cc
C++ compiler: c++
ARFLAGS: rv
CFLAGS: -O2 -g
CXXFLAGS: -O2 -g
QEMU_CFLAGS: -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong
QEMU_LDFLAGS: -Wl,--nxcompat -Wl,--no-seh -Wl,--dynamicbase -Wl,--warn-common -m64 -fstack-protector-strong
make: make
python: C:/Progamy/msys64/mingw64/bin/python3.exe (version: 3.6)
sphinx-build: NO
genisoimage:
slirp support: internal
smbd: "/usr/sbin/smbd"
module support: NO
host CPU: x86_64
host endianness: little
ninja: error: build.ninja:25741: multiple rules generate ../qemu-5.2.0/default-configs/devices/aarch64-softmmu.mak [-w dupbuild=err]

target list: aarch64-softmmu alpha-softmmu arm-softmmu avr-softmmu cris-softmmu hppa-softmmu i386-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu mips-softmmu mips64-softmmu mips64el-softmmu mipsel-softmmu moxie-softmmu nios2-softmmu or1k-softmmu ppc-softmmu ppc64-softmmu riscv32-softmmu riscv64-softmmu rx-softmmu s390x-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu tricore-softmmu x86_64-softmmu xtensa-softmmu xtensaeb-softmmu
gprof enabled: NO
sparse enabled: NO
strip binaries: YES
profiler: NO
static build: NO
SDL support: YES
SDL image support: YES
GTK support: YES
GTK GL support: NO
pixman: YES
VTE support: NO
TLS priority: "NORMAL"
GNUTLS support: YES
libgcrypt: NO
nettle: YES
XTS: YES
libtasn1: YES
PAM: NO
iconv support: YES
curses support: YES
virgl support: NO
curl support: YES
mingw32 support: YES
Audio drivers: dsound
Block whitelist (rw):
Block whitelist (ro):
VirtFS support: NO
build virtiofs daemon: NO
Multipath support: NO
VNC support: YES
VNC SASL support: NO
VNC JPEG support: YES
VNC PNG support: YES
xen support: NO
brlapi support: NO
Documentation: NO
PIE: NO
vde support: NO
netmap support: NO
Linux AIO support: NO
Linux io_uring support: NO
ATTR/XATTR support: NO
Install blobs: YES
KVM support: NO
HAX support: YES
HVF support: NO
WHPX support: YES
TCG support: YES
TCG debug enabled: NO
TCG interpreter: NO
malloc trim support: NO
RDMA support: NO
PVRDMA support: NO
fdt support: internal
membarrier: NO
preadv support: NO
fdatasync: NO
madvise: NO
posix_madvise: NO
posix_memalign: NO
libcap-ng support: NO
vhost-kernel support: NO
vhost-net support: NO
vhost-crypto support: NO
vhost-scsi support: NO
vhost-vsock support: NO
vhost-user support: NO
vhost-user-blk server support: NO
vhost-user-fs support: NO
vhost-vdpa support: NO
Trace backends: log
spice support: NO
rbd support: NO
xfsctl support: NO
smartcard support: NO
U2F support: NO
libusb: YES
usb net redir: YES
OpenGL support: NO
OpenGL dmabufs: NO
libiscsi support: NO
libnfs support: NO
build guest agent: YES
QGA VSS support: NO
QGA w32 disk info: YES
QGA MSI support: NO
seccomp support: NO
coroutine backend: win32
coroutine pool: YES
debug stack usage: NO
mutex debugging: NO
crypto afalg: NO
GlusterFS support: NO
gcov: NO
TPM support: NO
libssh support: NO
QOM debugging: YES
Live block migration: YES
lzo support: YES
snappy support: YES
bzip2 support: YES
lzfse support: NO
zstd support: NO
NUMA host support: NO
libxml2: YES
memory allocator: system
avx2 optimization: YES
avx512f optimization: NO
replication support: YES
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: NO
capstone: internal
libpmem support: NO
libdaxctl support: NO
libudev: NO
default devices: YES
plugin support: NO
fuzzing support: NO
gdb: /mingw64/bin/gdb
thread sanitizer: NO
rng-none: NO
Linux keyring: NO

Found ninja-1.10.0 at C:/Progamy/msys64/mingw64/bin/ninja.exe
WARNING: Could not create compilation database.
/mingw64/bin/ninja build.ninja && touch build.ninja.stamp
ninja: error: build.ninja:25741: multiple rules generate ../qemu-5.2.0/default-configs/devices/aarch64-softmmu.mak [-w dupbuild=err]

make[1]: *** No rule to make target 'multiboot.bin', needed by 'all'. Stop.
make: *** [Makefile:206: pc-bios/optionrom/all] Error 2

RuThaN_@RuThaNOnd MINGW64 ~/myqemu/qemu-3dfx/build

So tutorial is better, at least no more awkward sound patching but far from be good, it need more work..

Last edited by ruthan on 2021-01-22, 21:23. Edited 1 time in total.

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 535 of 619, by RayeR

User metadata
Rank Member
Rank
Member
mr.cat wrote on 2021-01-22, 09:05:

Actually I was thinking about Intel purchasing Altera and more recently, AMD buying Xilinx. It's one way of lowering the power consumption in the Cloud I suppose, but it's possible that FPGAs will have a bigger role in the future. The point was that we don't know what the future hw will look like. It looks there is already some arm work underway..

Yes I know intel bougth Altera 5 years ago and I had also some expectations but I don't see any of such technology was used in standard x86 CPUs. And I think same will be for AMD.
FPGAs are here for decades so we can guess how it will develop further. I don't see any significant speed up, rather they will increase number of cells and can contain some specific HW core blocks...

mr.cat wrote on 2021-01-22, 09:05:

As for docs & binaries, my guess is that there is a lack of time and/or interest. This is an enthusiast project and not on the list to gain any Red Hat funding, after all.
If you've done any coding you know how time consuming that is..and for most folks documentation is just boring as hell, so it's done last.

Sure, I did ( http://rayer.g6.cz/programm/programe.htm ). I know this take some time but sometimes when doing some complex process I found usefull to write a notes about all depencies, prerequsities, configuration etc. so when I return to project some years later I then quickly know how to setup and get in again. I think that the documentation of QEMU build is not needed to be made by author as he rather spends time with developing but maybe done by users who successfully replicated the process. And I really think that there are better ways to keep knowledges than expanding thread (not needed to be Github)...

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 4GB DDR3, 128GB SSD, GTX670(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo

Reply 536 of 619, by mr.cat

User metadata
Rank Member
Rank
Member
RayeR wrote on 2021-01-22, 18:38:

Yes I know intel bougth Altera 5 years ago and I had also some expectations but I don't see any of such technology was used in standard x86 CPUs. And I think same will be for AMD.
FPGAs are here for decades so we can guess how it will develop further. I don't see any significant speed up, rather they will increase number of cells and can contain some specific HW core blocks...

FPGAs don't make much sense in their current form because of all kinds of restrictions (not the least of which is cost, as you mentioned - but even this can change).
But because of Moore's law (and the competition getting heated again) they will be forced to investigate all kinds of solutions. This may well be one area of interest.
Anyways, hw virtualization is the tech you need for speed, whatever it will be in the future. If you demand accuracy, CPU-based solutions are probably the way to go. The speed isn't a problem for a lot of older stuff.

RayeR wrote on 2021-01-22, 18:38:
mr.cat wrote on 2021-01-22, 09:05:

As for docs & binaries, my guess is that there is a lack of time and/or interest. This is an enthusiast project and not on the list to gain any Red Hat funding, after all.
If you've done any coding you know how time consuming that is..and for most folks documentation is just boring as hell, so it's done last.

Sure, I did ( http://rayer.g6.cz/programm/programe.htm ). I know this take some time but sometimes when doing some complex process I found usefull to write a notes about all depencies, prerequsities, configuration etc. so when I return to project some years later I then quickly know how to setup and get in again. I think that the documentation of QEMU build is not needed to be made by author as he rather spends time with developing but maybe done by users who successfully replicated the process. And I really think that there are better ways to keep knowledges than expanding thread (not needed to be Github)...

Cool, thx for the link.
EDIT: Just took a peek at the site - so hello 90's, you're back, better than ever? 😁
Wow man, you've got a treasure trove over there. Got some serious flashbacks, no headache though 😁

What you described certainly sounds like an organized way to do your coding.
You're right of course there is this one thing, the churning out code, and there is all this "other stuff" around it that goes into making the thing actually accessible...

Hmmm, was that a subtle way of asking me to write some docs? 😁
Well, there's no harm in asking...My own goal regarding this project was simply to get a guest going in some form (I think I've reached that).
Currently I have no plans to advance the docs side beyond what we have in this thread, but at least others can now take a look and see what was needed.

@ruthan: Did you take a look at robertmo's Windows compilation guides if they help any? I think there are at least some switches that are needed for Windows.

Last edited by mr.cat on 2021-01-22, 22:59. Edited 1 time in total.

Reply 537 of 619, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie

@ruthan: Did you take a look at robertmo's Windows compilation guides if they help any? I think there are at least some switches that are needed for Windows.

Not really i have even my own guides, but dit not open them.. i guess that with right target it would work, but i gave it exactly 10 minutes no more, to check progress of guide..

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 538 of 619, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
mr.cat wrote on 2021-01-22, 09:05:

... This is an enthusiast project and not on the list to gain any Red Hat funding, after all.

Perhaps Apple could send me an M1 MacBook 13" to further my work into MacOS and Metal as an inspiration. 😁 😁

I don't know how well Rosetta binary translation would work on old Windows games from the late 90's til 2001's era. If it works, then it is no doubt the best option. DOSBox dynamic_x64 is the fastest CPU recompiler I have seen. I have measured scenarios that it could be as good as WHPX on Windows. Unfortunately, it doesn't work for ARM/AArch64. DOSBox dynarec, which is portable across multiple architecture, is slow, but for most of the DOS games, good enough. PCem has recently added ARM64 backend but without Voodoo. I can't talk much about it, their "fanboy-ant" community cannot swallow the facts 😜 🤣 for an open & direct academical scrutiny

QEMU has a strong "pro" developer community that don't crave to play old Windows games, but they are fully behind ARM/AArch64 ecosystem. QEMU TCG is well tested and optimized. No one had ever created a 3.2GHz ARM CPU. Using my 10X rule for dynarec, it could reach the performance of 300MHz CPU with TCG. 1st-party API pass-through such as Glide and OpenGL would have made quite a number of games playable on Apple M1. 3rd-party API pass-through such as WineD3D in my estimation may not offer good performance to be playable. (Unless some efforts spent to make at least D3D9 1st-party pass-through with MESA Gallium9 ..... hint ... hint 😜)

Otherwise, I am looking forward to get my hands on Pinebook Pro or anything better for evaluation.

Reply 539 of 619, by Bruninho

User metadata
Rank Oldbie
Rank
Oldbie
kjliew wrote on 2021-01-22, 22:53:

I don't know how well Rosetta binary translation would work on old Windows games from the late 90's til 2001's era. If it works, then it is no doubt the best option. DOSBox dynamic_x64 is the fastest CPU recompiler I have seen. I have measured scenarios that it could be as good as WHPX on Windows. Unfortunately, it doesn't work for ARM/AArch64. DOSBox dynarec, which is portable across multiple architecture, is slow, but for most of the DOS games, good enough. PCem has recently added ARM64 backend but without Voodoo. I can't talk much about it, their "fanboy-ant" community cannot swallow the facts 😜 🤣 for an open & direct academical scrutiny

AFAIK, if I understand correctly your comment, Rosetta 2 does not work this way. Rosetta 2 only "translates" 64 bit intel macOS apps/games for the M1, not Windows apps/games. Even WINE through Rosetta 2 wouldn't be practical for Windows games.

DOSBox had really good results both through Rosetta 2 and with a native version for M1. Yes, the dynamic core is fantastic but still needs more work, but works well actually until it has a segfault in Windows 98 after certain things are done on it (considering the DOSBox-X branch, actually it is their biggest hurdle to beat and be able to run Windows 98 and its game with a dynamic core).

PCem should fly and beat them all with an M1 build, but I didn't knew it did not have Voodoo yet. I tried all formulas to give my middle finger to VMware: QEMU, DOSBox, PCem. QEMU lets me play almost all the games, except one or two titles that require 3D acceleration. DOSBox has it but its slow. Same with PCem; They just don't do well on an Intel Mac, but are miles better on an M1 Mac.

And no, I am not a PCem fanboy. I am not a fanboy of any emulation in particular, I try them all when I want and choose the one that serves my desires at the moment I want to play something. For now, I still have an Intel Mac so I am stuck with VMware (has DX9 and 3D accel), while my iPad Pro runs UTM (QEMU GUI frontend app) well but without any 3D acceleration.

I understand the reasons why you dropped macOS support but Glide wasn't functional for mac anyway, I couldn't even find the libglide library for Glide support on macOS hosts running DOSBox-X.

"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.

List of ALL Android vulnerabilities