Hardware accelerated 3d for amithlon. What would be the best way?

[fishy_fiz]

As some of you may be aware Im somewhat of an amithlon fan. Ive used it on various machines over the years starting with an athlon xp 1800+ , through to an athlon64 3400+, and now my core2duo@3.86ghz. Finally with the last upgrade Im content with the performance of anything I throw at it. 68k UAE works nicely with aga games, even those that require a bit more grunt (breathless, xtrememe racing, etc.), fpse runs nicely, quake 1 and 2, descent freespace, etc. all run well at high resoultions, pctask runs at higher end 486 type speeds (havent benchmarked it, but Id suspect its at least that from the software I ran), even payback runs great at 640x480 using software rendered wazp3d with mipmapping, anti-aliasing, etc. enabled.

In short Im perfectly content with my amithlon box. It's not so much about the speed itself, but the ability to run software without thinking "if only it were a little faster".

Anyway, that said and done I'll get to the main point of this thread.

While impressed with the speed of wazp3d when software rendering, even with eye candy enabled Ive always been curious about hardware 3d acceleration for amithlon. There's plenty of rumors and suggestions around, but the only clue Ive ever found that I trust is in the docs of euae, although being that amithlon and uae work somewhat different Im not sure they'd exactly apply, and besides, it's not exactly what Im after (essentially being able to assign a pci lane to use elbox drivers).

Ultimately what Im trying to find out is where to start if someone was inclined to try to create thier own 3d drivers for use with amithlon. An Openpci driver using stormmesa seems the logical choice, making it not just for amithlon use, but hypothetically if I was to start a bounty for such a driver, what would need to be done exactly?

There's no reason os3.x users with suitable hardware couldnt be enjoying some of the titles os4.x/mos/aros people are. Winuae users in theory already could be given the ability to use hosts 3d hardware for warp3d. (infact I believe there's a 68k version of cube and tuxracer already, not to mention the titles Ive earlier mentioned).

Anyway, thanks for listening to me ramble and I'd appreciate any feedback on what exactly is required to get 3d acceleration working with amithlon.

[Heiroglyph]

I'd start with the Linux side.

The drivers in the Amithlon kernel have been modified to give more direct access from the Amiga side, so you'd want to extend that.  Looking at the diffs makes them pretty obvious.

First, get 3D working on the Linux side without using X.  Your best bet might be DirectFBGL.  This might give better 2D as well, the drivers are much better now than they were back then, but you'll need to keep those old Amithlon patches working too.

Then you'd probably want to modify Wazp3D to use your 3D extensions instead of software rendering.

I haven't really looked at Warp3D, but I'd assume it's some modified subset of OpenGL.  With any luck, you'd mostly end up with the calls being passed pretty much straight through to DirectFBGL.

[fishy_fiz]

The thing is though Id prefer to do things through the amiga os side, this is why openpci seems the best option, Id like any work done to work on both amithlon and any other amiga system using openpci. Given amithlons direct hardware access when not using linux drivers Id imagine it'd be a "cleaner" way of doing it as well. Pretty much all the framework is in place. There's already stormmesa and warp3d (waprd3d does indeed use a subset of gl).

To my knowledge its as "simple" as writing a driver for warp3d (wazp3d is probably the better bet as its easier to change if need be).

Thanks though for your input. While Im not 100% sure on the amiga os side of things I had even less of an idea about the linux side of things.

[Heiroglyph]

The part of the framework that screws the pooch is RTG and how Amiga-ish OS's like to keep things like this trade secrets.

Without an RTG video card driver you're dead in the water and the powers that be don't want you to do that.

They've already made all the 68k money they can, no sense in letting you continue using or extending it.  Now, go pay for your overpriced PPC like a good little consumer, OK?

You can't hear the disgust in my voice can you? :furious:

[matthey]

The thing is though Id prefer to do things through the amiga os side, this is why openpci seems the best option, Id like any work done to work on both amithlon and any other amiga system using openpci. Given amithlons direct hardware access when not using linux drivers Id imagine it'd be a "cleaner" way of doing it as well. Pretty much all the framework is in place. There's already stormmesa and warp3d (waprd3d does indeed use a subset of gl).

 I don't think OpenPCI would be used for more than to find the gfx card base address. After the base address is found, the gfx card register and memory accesses should theoretically go to the correct place. It would be possible to read a gfxaddr ENV: variable also as Warp3D did with the PPC version. This is not currently working with the 68k W3D libraries by the way. I checked. I didn't see with a quick look how the gfxaddr of boards is located in W3D. The OpenPCI.library, pci.library, prometheus.library etc. are not opened. The board base address is probably found through P96 or CGFX. A 2D P96 or CGFX driver that allocates it's memory directly on the card and possibly also has other restrictions is likely necessary. If you had a 2D P96 driver specifically for that card running directly on the card and good 68k emulation (some cards require 32 bit accesses for example), then I would say, give W3D a try. There's a lot of things that can go wrong though. Why not switch to AROS where Wazp3D can give hardware acceleration?

To my knowledge its as "simple" as writing a driver for warp3d (wazp3d is probably the better bet as its easier to change if need be).

 Writing a gfx card driver is anything but simple. A fully functional and mostly bug free gfx driver will take many man hours to complete. The Warp3D "driver" functions are not that difficult to reverse engineer for a driver and the data structures are already defined in Warp3D.h. The Wazp3D route would probably be better for most programmers and it has less bugs than the actual Warp3D drivers.

[fishy_fiz]

In regards to AROS, I already have an AROS box, but amithlon + os3.x is still my fav. amiga system. For all thier pros and cons none of the NG options really appease me the way os3.x does. I like the almost d.i.y. nature of os3.x, the millions of little bits and pieces to handcraft your system, and with the sort of grunt amithlon provides make the 2 a great combination (for my tastes). Basically Id just like to be able to extend my os3.x usage, even if it means I have to do some work, or pay others for that to happen.

And yes, I realise it's not simple to write a driver, hence my use of quotes around "simple"  

[woof]

Hello

Wazp3D can use hardware in WinUAE (and also AROS) so certainly something similar can be done in Amithlon
In Wazp3D/WinUAE it works this way
Wazp3D.library implement the 88 functions from original  Warp3D
Those functions call an other (simpler) library i called soft3d.library
soft3d works at low-level: it is something like a 3d driver (23 functions only)

soft3d.library exists as 68k on WinUAE side (It can render as software 68k)
soft3d.dll exists as x86 on PC side (It can render as software x86)
This soft3d.dll can also use the PC opengl32.dll for hardware rendering :-)

a given function in soft3d.library jump to same function in soft3d.dll with the "winuaenative" special calls that allow to call x86 code from WinUAE
(BTW many thanks to quarktex author for this part of the code)

So for Amithlon
1) Find how to do something like the "winuaenative" special calls
2) wrap soft3d x86 to make it use an hardware renderer (OpenGL)

Alain Thellier

Note: having soft3d give the great advantage to have only 23 "winuaenative" special calls from 68k to x86

[nicholas]

Might I suggest asking Karlos for his thoughts on the matter?

[jj]

Why ?
 
Isn't woof the author of Warp3d or maintainer ?
 
Wouldn't he know ?

[Crumb]

@fishy_fiz

Amithlon used a modified Prometheus driver with a Voodoo3 IIRC.

[fishy_fiz]

@Crumb

I vaguely remember something about Bernd showing amithlon running with an existing 68k voodoo driver, but my memory is a bit hazey as to the details. There was a little controversy about it though if I recall correctly. After reading the uae-jit docs in euae I started thinking maybe it was through the elbox drivers, as he gives a description there how to assign a pci slot that can use amiga drivers there. Whether or not its related to how he used a 3d accelerated voodoo3 in amithlon or not Im not sure.

Id like the find out the real story here. Ive heard many variations on it over the years, but never seen any proof to clarify the real story for me.

That aside though for now Im more interested in how to get 3d acceleration working in amithlon without the need for these sort of "hacks". A lot of it is beyond me at the moment, but the more I learn the more I can research it

[nicholas]

@Crumb

I vaguely remember something about Bernd showing amithlon running with an existing 68k voodoo driver, but my memory is a bit hazey as to the details. There was a little controversy about it though if I recall correctly. After reading the uae-jit docs in euae I started thinking maybe it was through the elbox drivers, as he gives a description there how to assign a pci slot that can use amiga drivers there. Whether or not its related to how he used a 3d accelerated voodoo3 in amithlon or not Im not sure.

Id like the find out the real story here. Ive heard many variations on it over the years, but never seen any proof to clarify the real story for me.

That aside though for now Im more interested in how to get 3d acceleration working in amithlon without the need for these sort of "hacks". A lot of it is beyond me at the moment, but the more I learn the more I can research it

Perhaps you could post your questions at moobunny as Bernie is a regular poster there.

[Karlos]

Why ?
 
Isn't woof the author of Warp3d or maintainer ?
 
Wouldn't he know ?

I think woof maintains Wazp3D, not Warp3D. He has, however, highlighted a number of bugs in existing Warp3D applications and drivers.

[Crumb]

@fishy_fiz

Bernd told me it was a modified Voodoo3 driver (from Prometheus IIRC although it's true that his first JIT for UAE supported using real PCI cards using Mediator drivers)

[Karlos]

Might I suggest asking Karlos for his thoughts on the matter?

Not much to suggest that I haven't repeated before like some broken record. Totally and utterly forget Warp3D as a driver layer. When all we had were Permedia2, CV3D and basic Voodoo, it was enough, but not any more.

My suggestion for OS 3.x, regardless of what hardware it is running on, would be:

1) Create a new driver layer, totally from scratch that is designed from the ground up to be as efficient as possible (as real 68K processors aren't fast).

2) Make sure the driver system works directly with suitable OS BitMaps and has no special needs (other than allocating VRAM for depth/stencil/texture buffers). Then provide as complete a set of accelerated 2D and 3D operations as possible. After all, OpenGL isn't just for 3D. Once installed, it should be also be possible to various patch graphics.library to use it since existing RTG sucks as far as acceleration is concerned. For this, some sort of fast, minimal locking protocol should be supported that allows the bare minimum of potentially-destroyed registers to be backed up and restored that is essentially independent of whatever is used for the main 3D stuff. This is essential if you plan to accelerate individual graphics.library calls as you can't afford the setup overhead of a typical W3D_LockHardware() style call.

3) Provide a transformation / lighting / clipping pipeline in the driver layer, abstracting it such that hardware specific drivers can leverage hardware acceleration for this on Radeon cards and that other hardware can at least interleave the necessary calculations on the CPU with the rasterizing operations going on on the card to get the best out of any parallelism that can be had.

4) Provide a thin-layer wrapper for OpenGL/glut around the whole thing.

5) Provide a thin-layer wrapper for Warp3D around it, bypassing any T&L stage.

You could look at Gallium and the like to get some inspiration, but I'd not recommend it for the basis of a 68K driver system as whatever you create needs to be designed and built with the limitations of existing 68K systems in mind and not just what is theoretically possible on far faster emulated systems. If you do it right, it should scale up on the latter but still deliver usable performance on the former.