Any way to emulate 3D from x86 or Apple Silicon?

@MartinW
Doesn't AmigaOS have a software fallback for 3D functions when the gfx card does not provide it? Somebody once tested Hyperion games Shogo and Tower57 when the sam460ex emulation was new in QEMU years ago and while it was unplayably slow they ran so are those games do their own 3D or how does it work? Somebody also mentioned that Wazp3D could do 3D in software so maybe that's also an option.

I've already discussed what would it take to get 3D support in QEMU on my Qmiga wiki page, the options that I think doable are:

-port Voodoo emulation

-write a virtio-gpu driver

-improve ati-vga

I pass the frirst two so they are up for contribution if somebody is interested, I may work on ati-vga but will probably take a year at least so if you don't want to wait look for other solutions but I don't see why software rendering does not work and fixing the PCI pass through if it has issues may also be interesting as that would give a better solution (not on your laptop though).

@balaton
Quote:AmigaOS itself doesn't, but most 3D software (at least games) do.
If software depends on 3D but doesn't include it's own software 3D rendering fallback code if the gfx hardware has no 3D support, using a software/CPU based 3D library like Wazp3D is the only option.

@balaton

Since it is a forum it is legitimate to ask questions
in terms of programming
how long does it take to make a port for voodoo qemu ?

is it so difficult ?
It takes a long time ?

it seems to me a legitimate question for those who follow the evolution of qemu

waiting for other solutions.

because if the voodoo driver is not right for the current emulation type, the silicon driver is not right either but it is still used anyway

Thank you.

@balaton

I know there really old mesa 3d ports to 68k on Aminet, but its useless, we need something that’s more up to date, we don’t really have OpenGL,
We have Warp3D Nova is OpenGL ES :-;
and then we have a Warp3D nova wrappers for OpenGL.
and then we have a Warp3D Nova wrapper for legacy Warp3D.
Wazp3d is software render for legacy Warp3D.
there is no software render for Warp3D Nova api.

@white
Voodoo3 emulation is included for example in bochs (x86 PC emulator) and WinUAE, porting it to QEmu should be easy.

However, 3D support, no matter if real hardware or emulation, on Voodoo gfx cards is limited to 15/16 bit screen modes, i.e. same problem as the 15/16 bit only SM501/2 driver - current AmigaOS software, 2D and 3D, expects there are, and is optimized for 32 bit, modes instead.

@white
Quote:
This question cannot be answered because it depends on who does it, how much time and experience that person has. It could take from a few weeks to forever: few weeks if somebody who can work on it day and night and already has experience with it, or forever if gives up before getting it to work. Realistically I think it would be a few months for somebody not working on it full time and maybe also needs to learn a few things along the way. Then maybe another month to get it in QEMU.
Quote:
I don't think it's difficult as it has been done before so only needs to be adapted to QEMU but this also depends on who would do it as understanding QEMU could take a bit of time for somebody never looked at it before. But again, nothing is difficult if you know how to do it but can be impossible if you don't so this depends on being able to learn what's needed. It might not take that long but the results probably don't justify the time spent on it at least for me it doesn't so I don't want to spend my time on this to get just another dead end limited gfx solution. That time is better spent on getting something better to work instead. But if somebody thinks it's worth their time then I won't stop them doing it.

On the other hand if somebody wants to start with it maybe better start trying to make a driver for just a Bochs VBE frame buffer, not even virtio, just the DISPI interface of -device VGA. This won't give 3D but it would give 32bit display and is a good start towards virtio-vga which is the next step towards 3D eventually. But starting with 3D from the start if you're not @Hans who did that before might be too much so starting with just the driver parts and VGA DISPI support for a simple frame buffer should be less work than porting Voodoo emulation and can then be further developed towards virtio graphics. So one could consider that or if @Hans could start such a project in open source then others could contribute to it otherwise you just have to waif for @Hans to finish it and then buy it in Enhancer Software X.Y

@balaton

It doesn't always have to be open source, they have already confirmed that writing GFX drivers is not an easy task and since we don't use an operating system that is open source, I see no point in making these drivers freely available to everyone.

We don't even know if @Hans is even working on a suitable driver for Qemu. Only a few developers seem to be able to do this, otherwise we would have solved the problem long ago, or there is simply no interest in it. I don't think @Hans is working on it at all because the whole thing has to be tested somehow or he's doing it completely alone.

It's also not that important as there are other issues that also need to be solved for a perfect Qemu AmigaOs4.1 experience, which is about as close as WinUAe with AmigaOs4.1 classic edition. But we're already going in circles again, the topic has already been discussed too often. Just my personal opinion.

@white
Quote:
What latest version and where did this become slower? If this is reproducible doing a git bisect to find the commit where it became slower might help (unless it's when sound was added which might increase interrupts and thus make it slower but there's not much that can be done bout that apart from disabling sound and checking if it's fast again without that). Your report is a typical "it's broken" without telling enough details to guess why so it you want this fixed you should give more details than that so we can debug and understant the problem better otherwise it will only be fixed by chance or remains broken.

@Maijestro
Quote:
So WINE stands for Wine Is Not an Emulator and it really isn't, it just implementes WIN32 APIs on top of POSIX so Windows programs needing these APIs can run as long as the CPU is the same as Wine does not emulate that. So Wine is not the reason for double translation but it comes from WinUAE translating PPC code to x86 code then Rosetta2 or whatever CrossOver uses to run x86 code on M1 translates that to ARM code. This is independent of wine and it's like running an x86 version of FS-UAE compiled for macOS x86_64 which I think should also work and you could drop Wine in that case. If CrossOver has it's own x86 emulator this may be faster too. But the problem ultimately is that UAE does not have ARM target for its jit only x86 (and PPC as I've learned from @kas1e's video) so you can't compile native ARM version of it or only without JIT which would again be slow.
Quote:
It can't have 3D as the chip does not have that but the case about 32 bit is not closed yet. It works under Linux and MorphOS and @m3x did not yet reply what is the problem why it's disabled in the AmgiaOS driver. Maybe he can eventually enable it in a further update or clarify why it can't be done.

How can I interject.

I think the topic has been discussed many times ...
There are various interesting projects involving QEMU and 3D.

https://docs.mesa3d.org/drivers/virgl.html

https://github.com/kjliew/qemu-3dfx

There is simply no one to do it in QEMU. I talk about it all the time, I don't think anything will change.

If I could and had the knowledge I would do it but I don't.
@balaton as he said will not take care of voodoo3.
No others willing to do it

Better to be happy with what is

@balaton

Just for info: Crossover is just Wine in a pretty wrapper that the company charges a fair bit of money to make it accessible to the end user. OK, that's really pretty unfair as they do make additional changes that improves it for Mac. I don't know what, but it was enough for Apple to use their engine in their recent "Game Porting Toolkit", but they do release their modified version so if you're OK with just a semi-manual process there is something called "Wineskin Wrapper" that I've used in the past. Like Wine in general (computer and liquid), when it works, it works and gets the job done.

If you really want to, you can opt instead for Flowerpot from the same people that did Amikit. It's Wine wrapped up in a wrapper dedicated to OS4. It works fine if you want to run it exactly as they want you to run it, even down to rom file names and so on, but deviate too far from how it is out of the box and you're back to messing under the hood with Wine. May as well go for one of the free options if you want to tinker.

Anyway, I've spent another evening not being successful in getting Voodoo3 to work under WinUAE even with White's settings file so at this point I think I may as well just throw in the towel, admit there is no emulated solution available to me as of today and go play something on Steam while I continue to (not so) patiently wait for my X5K to ship. When I have that then I can take another look at porting my code to OS4

[EDIT] Just to be clear, I'm not digging at anyone here, in case it sounded like I was. I started the topic because I wanted to check there wasn't an option I was missing. Looks like the answer is no and that's fair enough.

@balaton

Thanks for the reply,
don't get me wrong

I thought it was an easier job from a developer's point of view.
since qemu already implements voodoo inside x86.

but if times are these now I understand why it's not worth working on.

And there are also few developers for the Amiga now.
And everything is more difficult.

As for the slowness of Odyssey it is probably due to the x86-x64 compilation

I've also asked several times which is the best choice for the Ryzen

apart from :
configure --target-list=ppc-softmmu

if i have to add --enable slirp
or if I can omit it because it is automatically included.

or:
./configure --target-list=ppc-softmmu --enable-slirp --enable-lto --disable-dbus-display --disable-debug-info --disable-debug-tcg

A separate note if it can be useful if I use "Odyssey" with "Browservice"
Odyssey produces no "DSI" and closes normally with no errors.
I note that "Browservice" also takes care of the "audio" as well as "Chrome CEF".
In case it helps.

here my geekbench with the Ryzen 5800x: (Windows10)
https://browser.geekbench.com/v6/cpu/2175828

here my geekbench with the Ryzen 5800x: (Linux)
https://browser.geekbench.com/v6/cpu/2176426/claim?key=689669

@derfs
you who have a Ryzen 5600x
what line do you use to compile qemu ?
Thank you.

@white
Quote:
It doesn't implement Voodoo. The 3dfx fork people keep pointing to pathces the guest libglide to channel calls to the host where it's turned to some more modern API and does not emulate a Voodoo card. Taht's why it's x86 (more exactly Windows guest) only because the patched libglide is only implemented for that. To use that for AmigaOS you'd need to do something similar which might not be possible or maybe same amount of work as writing a guest driver for virtio-gpu which then would give much better results.

The Bochs/mame/WinUAE voodoo emulation does emulate a card and would work with exising drivers and porting it should not be too difficult but I don't want ot spend time on it and nobody else seems to have an interest in doing that either. If somebody wants to try it I'd suggest to start at https://osdn.net/projects/qmiga/wiki/DeveloperTips and read the info linked from that page then look around in qemu/hw/display and try to understand a simple display device such as bochs-display or next_fb then try to change the voodoo emulation from bochs/mame to work that way. That's all it takes and time and determination by somebody to go through with it and learn what's needed if not already knows. There's no magic programmer talent people have to born with is required just being able to think logically and spend time with details so anybody who can do that could do it unless gives up before doing that.

@balaton

Maximum respect for your work.
but it's hard to find someone trying to emulate amiga
or rather who develops an emulator for amigaNG.

it is therefore normal to make requests and ask for information.
it's just that.

Thank's for your job.

@MartinW

Quote:
If you've got a Radeon R7 270X working with qemu, then you should be able to use modernish OpenGL. Have you tried running known working 3D games? For example: Spencer Demo, or voxelnoid.

The Voodoo3 is very old, and will be restricted to OpenGL v1.3 (roughly) via MiniGL. So, it would be a big step down from your R7 270x.

Hans