8bit, realtime, 640x480, gfx stream to chip ram...

[Jose]

Hey, First of all, I'm just curious about this. Slowly leaning as it happens but time is scarce, even to be here.
I was wondering if it's possible to have a video stream of 8bit constantly being written to chipram. Talking about realtime here, so it would have to be 640 x 480 x 8bits x 24frames /(8bitsx1024bytes)  Kilobytes per second. This gives more or less 7.x MB/S. I've checked some benchmarks on the net but the very few ones I found have an average writte speed to chipram of about 6MB/s in high end Amigas. Actually some of them have more than 7 but that's probably not in 640x480. This mode probably slows dow things more so it's not possible. Well shame isn't it. I know some video progs work by just writting in the necessary info (just the different bits), but uncompressed would be more cooler.

[Karlos]

Chip ram, eh?

Tricky to get that throughput. For a start, you can't write every cycle and chip ram is uncacheable.
On 060 systems you can accelerate chip ram writes a bit by marking the area you want to write to as imprecise in the data cache. IIRC patches such as speedychip do this.

Basically you are up against the top limit of the chip ram bus however. If you want to synchronise to a display refresh you'll need to do triple buffering (double buffering can stall, with triple you can always be writing to one buffer even whilst the other two are involved in the switch).

Ultimately I'd expect to get the full framerate, using a delta buffer of some kind is the only realistic way forward.

-edit-

And it goes without saying that you want 32-bit aligned transfers...

[Jose]

Ok, I'm gonna say what my idea was. It was to have 24 bit to HAM8 conversion in fast ram, and send it to chip ram. But I REALLY need to get more informed about some stuff.
Yeah, delta should do it, but with delta you can't have like  a screemode or can?
I figured that the benchmarks I saw are probably from systems with that patch already installed cause the vaues of the 060s are higher than the 040s tested and an 040 can pump more than 7 Mbs.
An idea I had was to use only 6bits, since HAM8 uses 2bits for control and the other for data. I'd be stuck to the chosen base colors though. But maybe if I only changed them when needed  it wouldn't be that much additional space. So using 6bits it would be possible. BUT: The data is supposed to be continuous (the control bits are mingled with the data bits), so I really can't take advantage of using only 6 bits can I (the space of the control bits in the data has to have the control bits, so I'll end up being able to writte  less data at the same time?
Give me a discount here, cause I need to dig more into some stuff, but I think the ideas are correct.
If there is a way  to make the last idea work let me know :-o

[Karlos]

Well, I meant delta buffer as in 'compare with last frame and write only changed areas' buffer.
IIRC, lots of 'high res' c2p stuff does this (like ShapeShifter video drivers). So it's not a problem to use different screen modes, your delta buffer just has to be an appropriate size (same as the screen, I guess). Perhaps 'comparison buffer' would have been a better phrase for me to use :-)

However, using ham8 would most likely result in most of the 'comparison' buffer changing every frame anyway (due to the way ham renders colours using ramping) so it might end up slower!

If you only use 6-bits of the ham, you waste the colour potential completely. For a typical ham image, most of the pixels on screen are 'ham' colours rather than the base colours (unless you have a very simple image that is).

A point to note, 24-bit -> ham conversion is not a trivial process, especially for 680x0. It's likely to dominate the rate at which you can pump frames out at your chosen resolution (640x480) long before you get into the bottleneck of writing the data to chip ram.

I don't want to sound all doom and gloom here. The sort of thing you are thinking about has been done (not sure about at such a high resolution though).

You should look at AMP (AmiDogs Movie Player) to see some good quality 18-bit ham output stuff. The documentation describes the process he uses.

Incidentally, you may have seen a lot of seemingly low resolution 2x2 (ie 160x120) ham8 animated stuff in demos etc. In reality, many of these are actually 640x120 ;-)

As you probably know, from any starting colour it takes a theoretical maximum of three pixels for the ham colour ramping to get to any other colour - unless of course a well chosen base colour can be used.

So, the trick is that using 4 pixels on screen for 1 in the image allows the ham colour ramping mechanisms to hit the desired colour on every '160' width pixel in the image. Used a lot in demos ;-)

[bloodline]

Jose wrote:
Hey, First of all, I'm just curious about this. Slowly leaning as it happens but time is scarce, even to be here.
I was wondering if it's possible to have a video stream of 8bit constantly being written to chipram. Talking about realtime here, so it would have to be 640 x 480 x 8bits x 24frames /(8bitsx1024bytes)  Kilobytes per second. This gives more or less 7.x MB/S. I've checked some benchmarks on the net but the very few ones I found have an average writte speed to chipram of about 6MB/s in high end Amigas. Actually some of them have more than 7 but that's probably not in 640x480. This mode probably slows dow things more so it's not possible. Well shame isn't it. I know some video progs work by just writting in the necessary info (just the different bits), but uncompressed would be more cooler.

I think if you try it... you will find this really isn't possible... From my own experience anyway.

I suggest you look at a GFX card for such activities...

[Karlos]

bloodline wrote:

I think if you try it... you will find this really isn't possible... From my own experience anyway.

I suggest you look at a GFX card for such activities...

I may be wrong but I think he's looking at it from a 'lets see how far we can push AGA' point of view.

This kinda stuff is good fun :-)

To be honest, it may surprise some but from the tests I got folks to run a while ago hinted that most graphics cards available for amiga (be it 'native' or via a PCI bridge) aren't much faster than AGA when it comes to shovelling data into a framebuffer :-)

Of course, you don't have c2p to worry about, but once you get to 68040 most c2p routines operate at copy speed anyway.

For example, my 68040 @25MHz can pump data to the BVision at about 10Mb/sec for longword aligned writes.

A 68060@50MHz / Mediator4000 / Voodoo5 gave a similar result.

Not such a vast improvement over AGA's 7Mb/s, is it?

Having said that, in Jose's case I reckon just converting 24-bit to ham8 without using the 'several pixels wide' trick would be the killer anyway.

[Jose]

I may be wrong but I think he's looking at it from a 'lets see how far we can push AGA' point of view.

Of course  :-D  :-o

"..Having said that, in Jose's case I reckon just converting 24-bit to ham8 without using the 'several pixels wide' trick would be the killer anyway."

You're starting to make me think I really got some good stuff, at least in ideas, algorithms, that's how programmers call it right?.  I think I have damn  good one  for that.  Now I have to better dig some 68k programming. I wasn't even worried with the speed of 24bit > ham8 conversion at all.

EDIT: Having thought about it there might a big problems here, because HAM is planar and 24bit is chunky. But if you were refering to 24 to HAM8 chunky I still think my algorithm will rock  :-D
 

Back to the chipram bottleneck:

"If you only use 6-bits of the ham, you waste the colour potential completely. For a typical ham image, most of the pixels on screen are 'ham' colours rather than the base colours (unless you have a very simple image that is)."

But that was exactly my idea. Ham colors are really just 6bits, based on the previous pixel. So if most of the colors on a HAM screen are not base colors, I'll need to change only 6 bits most of the time.
[EDIT]
This part and the following one was wrong I'll still need the control bits to specify wich hue (R, G or  B) I want to change. Doh!

 

[Karlos]

Yep, for planar gfx, you can still do 32-bit writes.
In fact, it's essential if you want the best speed utilisation.

Consider, for example, 8 successive 32-bit writes, one to each succesive bitplane results in a horizontal span of 32 8-bit pixels.

Most c2p alogrithms do something like this. Generally for whole screen spans :-)

You could interleave some code so you reduce chunky 24-bit to an 8-bit ham pixel and c2p at the same time. Maybe...

You need to talk to some proper demo coders, really. I'm afraid I went the gfx card route some time ago and as such never got too much into AGA programming.

Pity really, it was a lot more entertaining :-)

[Karlos]

Hey, does anybody know if the akiko chip actually cares about the format of pixels it converts?

I assume its a dumb c2p engine only. In which case chunky ham8 is a 'real' possibility on a CD32 :-D