Idea...

[Karlos]

In a post AOS4 / MOS world, would a grex style busboard for BlizPPC / CSPPC with a genuine AGP controller be feasable?

Speed issues aside, the biggest arguments I heard against genuine AGP capable bus boards was the lack of a suitable 680x0 friendly northbridge. Moving to PPC presumably opens up the possibility?

I realise that such a product is unlikely to be ever manufactured, but is it feasable?

[Karlos]

Yes, you are correct. Remember however, the g-rex is the fastest PCI expansion for classic amigas, provided you have the h/w to use it.

I was actually wondering how much of the existing bus speed limitation is down to 680x0 support etc.

For instance, some systems with 68060/grex can hit 40Mb/s for CPU->VRAM. Before anybody says thats a myth, I have the test results to prove it. But it was a minority of cases - not sure what the exact configs of those machines are.

That suggests to me that it is possible to get more out of the BlizzPPC / CSPPC expansion connector than most people do. If we had only logic for the PPC side and totally ignored the 680x0, perhaps the old arguments dont apply.

[Karlos]

@patrick

Well, its a bit involved. It was designed to measure the performace of my direct-to-video ram pixel translations (a backend part of a system I have been designing).

However, if you run it without specifying a source pixel format, it just performs what is basically a copy operation. The code for this is loop unrolled asm, moving 16x32-bits in the main loop. It so happens that this gives a pretty good estimate of the bus speed which has proven to be the limiting factor on all systems so far, even directly connected cards like the BVision.

Later, when looking at 3D issues, I found I needed a quick test for VRAM access badwidth (limited by the speed of the bus, basically) and it was handy to use my existing program.

As for line transfers and the like, I am not sure how likely that is. VRAM especially is usually mapped as non cacheable due to its inherently volatile nature.

The PPC can indeed address anywhere the 680x0 can. That was part of the design aim of the first PPC cards.

If, however, the 680x0 can't write at full speed because of the bus logic limitations, its fair to assume the PPC wont be much faster. Hence my thoughs about better bus logic(northbridge or whatever)  that might be available for PPC only systems.

[Karlos]

@patrik

Well, you could only really use move16 for the cache aligned parts of large writes.

On cards like the blizzard Im not sure that the move16 is really much faster than 4 moves...

[Karlos]

Yeah it would.

I cant see it for VRAM mind, but other areas might be cacheable.

The 40Mb/s transfer was for CPU regsiter -> VRAM (so no system memory data read). That was on a CSPPC 060 @ 66Mhz.

As for the refrresh thing, I render to an offscreen buffer during a locked call, then update the display afterards.

You can never eliminate the actual display refresh (that draws the screen) but in SGRAM rated at 10ns or better, the MB/s you are getting are always bus limited, not VRAM limited.

-edit-

Anyhoo, the copy/clear/set routines are part of my Mem class and implemented in 680x0 assembler. So the 40Mb/s test was for basically a 16x block of "move d0, (a0)+" type stuff.

I might have to see about testing/comparing a cache aligned block of VRAM using a move16 loop. You got me curious now...

Better still, write a dedicated test for VRAM access times only (the pixeltest has a bunch of conversion options that are irrelavent to the argument and for timing my conversion routines only).

[Karlos]

I think I should point out that I don't personally have a G-Rex dude :-) These were results returned from people kind enough to run them here..

Im sure the MMU trickery can be  can be done from within the ASM, but I'd definately need to get the manual out since supervisor model chip dependent coding isn't something I do much of.

As it goes, I was measuring the speed of direct writes (rather than bursts) originally for a good reason. I needed to estimate how quickly I can write data to a GPU's rasterizer engine (often a FIFO buffer). Some of these are command registers and burstmode / out of order writes would totally screw it up so were never considered in the testing strategy.
As with VRAM, except for perhaps the slowest 3D GPU used (the ViRGE), such transfers are always limited by the bus performance.

[Karlos]

@patrik

You sound far more than capable enough to write a test application yourself - you don't need me :lol:

Incidentally, have you ever tried BusSpeed?

-edit-

Incidentally its 5am here, so if I don't make any sense, you'll know why :-)

[Karlos]

Heh, wasn't a hint, I just mentioned BusTest as an 'already existing' tool for pure bus speed estimations ;-)

I will look into the writethrough cache fudge for register<->VRAM at some point, but I can't really promise to spend much time on it for the forseeable.

If it works, however I have a use for it already ;-)

-edit-

Incidentally, your'e not a GRex owner by any chance are you ? :-) You seem mighty interested in seeing what can be wrung out of it performance wise. An almost unhealthy degree in fact :-D

I'm not particularly concerned about getting one as it isn't developed anymore and hence unsupported, but it definately had the most muscle of the exisiting solutions.

Mediator + SharkPPC (if ever released) would no doubt beat it hands down, however.