Off topic: Warp3D stuff (branched from AmiQuake2 AGA thread)

[Crumb]

One idea I have is that if Warp3D were to include a primitive T&L pipeline, GL could be improved on this old hardware. A lot of time in the driver is wasted waiting for the GPU FIFO when instead it could be performing transformation and clipping.

Is there any "legal" way to put new commands into the ring buffer of the gpu (aka GPU FIFO)? Or just examining the GPU registers to see if the read pointer and write pointer are equal and assume it's ready to add the new commands there? I guess p96/cgx waits until GPU FIFO is ready, otherwise crashes may happen. I guess that the difference between CGX and P96 in this respect is that CGX driver will probably offer a "legal" way to add new pointers to command buffers and with P96 you can't "interleave" commands from both systems.

So with p96 and a Radeon:
1.- seek base address of the gfx card
2.- reserve and lock memory for textures and command buffers
3.- check the addresses of write ptr and read ptr, if both are equal GPU FIFO is empty.
4.- write command in the FIFO to execute the chunk of commands pointed in the command buffer
5.- pray :-)
I ask because it would be nice to have a 68k Warp3D (or Wazp3D probably) driver for Radeon 9x00 :-)

And to continue the hijacking... any plans for a BlizzardPPC OS4 scsi driver? I guess you could add some "legal" way to add commands to move lots of data using the scsi chip in parallel to the cpu*:-) And since G-Rex is supported in NetBSD are you thinking about OS4 support too?

[Crumb]

I'm not sure what you are asking exactly.

Oh, sorry, I mean: in a hypothetic case one wanted to create a Warp3D/Wazp3D driver for m68k would there be a "official" way to add stuff to the ring buffer?

The R100/200 3D drivers communicate with the radeon's ring buffer through the same system resource that the 2D driver does. Just to be clear, my musings above are in relation to the Permedia2 specifically.

Since m68k warp3D also runs on CGX drivers I guess that the system resource is "new" or just p96 related.

Purely hypothetically, if I were to retrofit a 3D T&L pipeline to Warp3D I'd probably do so by exposing an interface that's not a million miles from the model already defined for the R100/200. Some methods to set transformation matrices to be applied to geometry, texture coordinates, lighting and material properties and clipping planes. In the corresponding drivers for R100/200 these would be mapped onto it's hardware implementation of these things for maximum efficiency.

I guess Wazp3D does something like that with its Warp3D wrapper for windows OpenGL.

However, as it's still a fairly low-level model, it would lend itself to drivers like the Permedia also. In the Permedia, data registers and command operations are loaded through a FIFO that can be written to directly or through DMA from a buffer.

Perhaps you could start reserving the buffer memory in BlizzardVision memory so it accesses gfx ram, once you get that working, use a buffer in fastram, addresses may be different thought

As I said, both the 3D and 2D drivers use the same resource on R200/100. However, Warp3D takes owenrship of the hardware system so at least when a hardware lock is in place, nobody else can be submitting packets to it. Outside of that situation, anybody can write to the resource. That's what the command processor / ring buffer was intended for.

is that resource a flag in a register of R100/R200 or a real AmigaOS resource?