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

[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.

[wawrzon]

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

alain is sure one of the best informed people available and willing to help, what concerns functionality of w3d as of today. of the people who speak out openly its either kas1e, matthey or you who could be named along him. if there is anyone else, they do not show up.

[matthey]

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)

Was the Voodoo 3 driver modified to work with OpenPCI? It's possible that Warp3D would work with this P96 driver if all the board information needed could be obtained from P96 as I suspect (OpenPCI->P96->Warp3D).

[woof]

Hello

Yesterday I maded some web searchs and I wasnt able to really found out : How can I call "native x86 code" within Amithlon ?
==> this is the most important thing to find out

So ... people that want a native Amithlon driver : just found the necessary docs and compilers to "call "native x86 code"
Especially usefull will be an example source and all the compiler/sdk stuff to rebuild it

@Karlos
About future legacy Warp3D for New Amigas I think the better/simpler  will be to have Wazp3D -> Mesa -> Gallium (like Aros do)
Of course to be efficient it will not be 1/1 calls (each Warp3D call -> an OpenGL call)
but something smarter that call OpenGL only when necessary (ie states changed)

Alain Thellier - WaZp3D Author

[fishy_fiz]

Ive just used the 68k hosted cross compiler to generate x86 amiga os bins (http://aminet.net/package/dev/gcc/x86-ami-gcc). Once its compiled a person just needs to use runelf to run the exe. There's also linux and ygwin hosted cross compilers, but Ive never used them.

Is that what you was asking? Id be a happy man to have an amithlon native wazp3d, even software rendered, so if there's anything I can do to help please let me know

[jj]

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

That comment was no slight on you btw Karlos
 
And I meant Wazp3d not warp

[LaserBack]

Hello

Wazp3D can use hardware in WinUAE (and also AROS) so certainly something similar can be done in Amithlon

wazp3d do no use any hardware in winuae, it uses the x86 cpu only to call functions and it is very buggy
idem for aros...or ppc...or amithlon  or real amiga ....only uses cpu

the only wrapper that uses real hardware acceleration on winuae is quartex warp3d library which is much faster and better than wazp3D....cause it call directX in windows and of course will use the hardware of the gfx card

[woof]

@laserback
I WROTE Wazp3D (and also use it almost every day) so believe me :
Wazp3D can use hardware in WinUAE since version 48
Wazp3D can use hardware in Aros since latest version 50
(You can use Aros port with Cow3D on Aminet)

BTW i have also quarktex sources : it dont seems to use directx but mostly opengl

@fishy_fiz
That is not enough to have soft3d compiled as x86 : What I need is calling several functions (23 functions in fact) with parameters in this soft3d-x86

What I need is something like "call an x86 function with parameters from inside a 68k program"

Alain Thellier

[LaserBack]

@laserback
I WROTE Wazp3D (and also use it almost every day) so believe me :
Wazp3D can use hardware in WinUAE since version 48
Wazp3D can use hardware in Aros since latest version 50

ok you say you are the author but it seems that hardware accel on wapz3d is not working very well cause quartex library is much faster
the other day I tested blitzquake (aminet) on both libraries......quartex library was much fast and smooth..
even with wazp3d the textures on blitzquake are not correct

[fishy_fiz]

@woof

The main 2 "substantial" big endian x86/amithlon things I can think of off the top of my head are ahi and povray. Would looking at the sources of them be of any use (particularly ahi maybe?).

Oh, and I thought you might be interested to hear that v50 of wazp3d is working much better for me now. Some of the glitches were from an unrelated problem.

[woof]

>with wazp3d the textures on blitzquake are not correct
textures certainly you dont have installed Wazp3D correctly
See this image it is Wazp3d with hardware rendering
http://thellier.free.fr/quake-hard2.png

You must also set with Wazp3D-Prefs:
Renderer: hard
AntiAlias Image

Use Filtering

>ahi and povray. Would looking at the sources
just do it and if you find a "call to an x86 function with parameters from inside a 68k program" just let me know...

>v50 of wazp3d is working much better for me now
I told you ;-)

Alain