Accessing RTG + 400 MHz ARM on Warp 560

[VladR]

Apparently, there's a new 68060 accelerator: Warp 560, with 256 MB RAM and a 400 MHz ARM, supporting up to 1920x1080 / 60 Hz


http://www.amigawarp.eu/1_6_warp560.html?a=gallery1


[ Show youtube player ]


It would appear that it is impossible to access the 400 MHz ARM directly currently. Unfortunate.


So, how would one access the RTG then ? I'm currently using CyberGraphics.library in my 3D engine, though I really only use it to set up the video mode (and under WinUAE to convert the FrameBuffer after I draw it). Everything else is done on CPU, including drawing.


Would one have to use graphics.library ? I checked my NDK_3.9/Documentation/Autodocs and couldn't find any RTG library specifically, even though there's about ~95 files.




More specifically, I would probably only use 2 functionalities:
1. Line Drawing - to draw each scanline of the polygon - probably method Draw () ? I also see WritePixelLine8 () that could be used for this.
2. Sprites - to draw some HUD elements and some other FX into framebuffer


Is there maybe some more recent graphics.library version that would be able to fill whole polygon via single library call ? I couldn't find anything in my version, but perhaps I missed it.


That might be actually pretty fast on a 400 MHz ARM, if I submitted 3 points (for a triangle) or 4 points (for a quad) and the ARM would fill it, without having to do a scanline traversal on main CPU !




Now, I'm still busy working on the game, so this is more like a hypothetical future exercise. Just wanted to figure out how one would go about it, out of curiosity.

[Samurai_Crow]

ARM AROS has Cybergraphics 3 emulation in its version of Graphics.library. Just saying....

[VladR]

Cool, so I could literally not even have to change anything, and just work with CyberGraphics.library.

Or did you perhaps mean that graphics.library over there is implemented via CGX ? Like an additional layer ?

Meaning, I would call a function from graphics.library, but its internal implementation would be based on CGX ?

[VladR]

Also, I just noticed they are running AmigaOS. What are the implications of that on RTG and related libraries ?

It also appears they are writing cswarp.library themselves, so perhaps it would be possible to include an ARM code to rasterize a polygon and let the thing fly at 400 MHz.

Or, write a simple library with 2 functions:
- TransformPolygonArray ()
- RenderPolygonArray ()

Then, the 68060 would only have to prepare a list of visible polygons on the scene (per frame), make 2 library calls (per frame) and the 400 MHz ARM could work in parallel to the 060.

Imagine you wouldn't destroy 95% of CPU's frame time on rasterizing, pixel by pixel, but instead it would be available for other stuff.

Now, the closest thing to ARM I ever worked with is probably the Jaguar's RISC GPU/DSP assembler. Which was a b*tch as the code had to fit into tiny 4 KB cache (which has huge implications on type of gfx algorithms possible to implement in such tiny space)

Surely it shouldn't take more than a week of work to write 2 such functions, though ? It wouldn't even have to be super optimized, at 400 MHz.

[Samurai_Crow]

A 400 MHz ARM is not 4 times faster than a 100 MHz 68060. If it's a 400 MHz ARM7 it's about the same speed as the 060. Optimization is still needed.

[VladR]

Originally Posted by Samurai_Crow

A 400 MHz ARM is not 4 times faster than a 100 MHz 68060. If it's a 400 MHz ARM7 it's about the same speed as the 060. Optimization is still needed.

I didn't say it's 4x faster than 060.


My frame of reference is Jaguar's RISC running at 26.6 MHz. I wrote a lot of code for that RISC, manually rearranging ops for best possible pipelining - for example my transform routine hid the latency of DIV down to just 1 cycle by working on other parts of pipeline while DIV was being computed.


Now, ARM's instruction set will be different but it's pipelining approach will be similar, though from what I hear about ARM, all the register conflicts are up to coder on an ARM (slightly less of an case on Jaguar, but more than outweighed by drastic HW bugs that basically impacted the way you write your code everywhere).


Over 90% of frame time is spent on traversing the scanlines (if you want anything more than just couple polygons, where the transform cost might by heavier).


That scanline traversal code, all it used was ops like add/sub/bitshift/cmp/load/store. And all 32 registers.


Surely the ARM has the exact same ops (just different syntax) ?


From that standpoint I would reckon that the 400 MHz ARM would be roughly 400/26.6 = ~15x faster than Jaguar's 26.6 MHz GPU. Assuming you can realistically get 200 MIPS out of the ARM here (without any shady shenanigans) - would need to see the exact specs of the pipelining and scheduling in the CPU's PDF.


So, if I could get around 2,200 scanlines per frame on Jag's RISC, I'd expect somewhere around 15*2,200 = 33,000 scanlines on the 400 MHz ARM.


Reduce the framerate by a factor of 3x down to 20, and you got ~100,000 scanlines. That's helluva detailed 3D scene, for sure. Minus the fillrate (pixel-fill bandwidth), of course - as we know nothing about the system's bandwidth and how is external RAM accessed from the ARM (that can only be benchmarked on a real device).