RiVa AMMX Benchmarks

[grond]

Originally Posted by britelite

Well, yes, the platform has stayed static for so long which is pretty much the whole idea and what makes it fun.

"Fun" is subjective. On a more objective side it keeps the demos and their technical level comparable. That's why I don't think that the demo categories for Amiga compos will change.

And as I've said, why limit myself to the Vampire/Apollo-core if I only wanted more power

For me the reason would be that I want to do coding in 68k assembly on an OS that doesn't stack gigabytes of software layers on top of each other. On the other hand I'm tired of doing chunky-to-planar stuff and stacking static 2-bit planar gfx on top of 6-bit c2p'ed gfx, limited palettes and the impossibility of more computationally deep effects. I rather spend my time doing a precise sine approximation than using tables for everything a.s.o. Coding for the 080 is refreshing.

[Zetr0]

I will put the cat amongst the pigeons here :

If an ASM coder codes for an 060 - but lets say shuns the V2 - doesn't this belay the point of programming on an 060?

After all, if speed isn't your thing surely an 020/030 is more applicable as more people have access to it.


Now I will probably answer my own question :

The 060 has a defined *static* ISA as well as an MMU and FPU where as the V2 is in state of flux (optimizing and additional register sets included) - in this regard until the V2 core is matured and finalized - it will make it diffcult to coders as it would be like playing a game of football with the goal posts changing position after every kick.

In the meantime :

How cool is it that I can watch Top Gun in 640x480 on my A600!!!!

As a developer - think of the possibilities of FMV used in conjunction in game or applications - freaking exciting if you ask me!

[britelite]

Originally Posted by Zetr0

After all, if speed isn't your thing surely an 020/030 is more applicable as more people have access to it.

Because when I don't want speed I actually code for the A500

When it comes to the demoscene 060/AGA has been the de facto accelerated Amiga platform for almost 20 years, which is why people stick to the 060. And in the past few years there's also been a renewed interest in going back to the basics and doing stuff for the A500, which I think is a good thing.

[wawa]

Originally Posted by britelite

which I think is a good thing.

it is a good thing to serve the lowest common denominator and widest possible audience where applicable, i agree. but i do not feel that apollo proposal availability must necessarily be in conflict with this especially as soon as we agree upon the above.

extra stuff like instruction set or api extensions may be sparely used where they are of notable importance for speed or functionality, similarly like asm inlines. the thing is not everybody is convinced that it would be most beneficial attitude. some folks insist on coding everything in 68k asm, others say 68k is too outdated, they need os4 interfaces.

[JimDrew]

Originally Posted by buggs

The team members are on a constant lookout for people who are willing to lend a bit of their spare time contributing something to the project. To underline a point here: there are members like for example Jim Drew (Fusion, PCx) who keep Gunnar and Chris on their toes concerning compatibility to existing software, irrespective how badly the code in question was abusing the 68k.

This is absolutely true. *My* focus is to keep Gunnar/Chris grounded so that software compatibility is the most important goal. It doesn't matter if you have the fastest car in the garage if you can't get traction!

The additional instructions (some of which have come as direct result of PCx), are a welcome addition to the core. The recent AMMX usage (I say recent, but AMMX has been in the core for awhile) gives a FREE boost in performance by using the instructions. Nobody is forcing you to use those instructions in your code, but I would say it is rather "clever" to use those if they are available.

I write only in assembly (no matter what CPU I am using), and have since 1979. The 68080 (a name I don't particularly care for really) is an excellent superscaler CPU core, with lots of flexibility from a programmer's stand point. It's also a breath of fresh air for Amiga enthusiasts who want the fastest possible CPU. I don't see anything wrong with the Vampire project - and if I did, I sure as hell would not be involved.

[TuKo]

RiVA 0.50 sources have been released publicly on Aminet.

http://aminet.net/package/gfx/show/RiVA-src

Let's skilled ASM coders improve it now

[grond]

Finally talking ends and coding begins.

[pandy71]

Is there any way to estimate hypothetical speed gain if instead YCbCr color space YCgCo color space will be used in video source (assumption it is easier to recode on PC video from YCbCr to YCgCo and at the same time some processing can be performed - for example resizing to match Amiga graphics HW capabilities).

https://en.wikipedia.org/wiki/YCgCo#YCbCr_color_model

[meynaf]

Originally Posted by pandy71

Is there any way to estimate hypothetical speed gain if instead YCbCr color space YCgCo color space will be used in video source (assumption it is easier to recode on PC video from YCbCr to YCgCo and at the same time some processing can be performed - for example resizing to match Amiga graphics HW capabilities).

https://en.wikipedia.org/wiki/YCgCo#YCbCr_color_model

There would be some speed gain but not very much because current YCbCr conversion is normally quite optimal and so this conversion doesn't really play a major role on overall decode time (i know for jpeg still images but for video it's just a guess, though). For a coarse estimate i'd say something like 10% gain.

I don't think it can be easily tested because YCgCo isn't supported in MPEG-1 (only format supported by Riva).
For this MPEG-4 support has to be added (but h.264 would be a lot more cpu intensive).

[Samurai_Crow]

There is one thing that is right about Meynaf's line of thinking. The Vampire version of RiVA uses a screenmode that implements the luminance and chrominance color space conversion to RGB thus AMMX is not the only optimization.

[grond]

Originally Posted by Samurai_Crow

There is one thing that is right about Meynaf's line of thinking. The Vampire version of RiVA uses a screenmode that implements the luminance and chrominance color space conversion to RGB thus AMMX is not the only optimization.

AFAIK at least some RTG cards also have such modes.

[Samurai_Crow]

Originally Posted by grond

AFAIK at least some RTG cards also have such modes.

True.

[pandy71]

Originally Posted by meynaf

There would be some speed gain but not very much because current YCbCr conversion is normally quite optimal and so this conversion doesn't really play a major role on overall decode time (i know for jpeg still images but for video it's just a guess, though). For a coarse estimate i'd say something like 10% gain.

I don't think it can be easily tested because YCgCo isn't supported in MPEG-1 (only format supported by Riva).
For this MPEG-4 support has to be added (but h.264 would be a lot more cpu intensive).

MPEG-1 fully support YCgCo (just set matrix coefficient as 8 - normally it is reserved for future use in MPEG-1 and MPEG-2 but it is fully specified for H.264 and H.265 - problem is that nobody use MPEG-1 so it is uncommon practice to use YCgCo as it is not popular even nowadays but Amiga have limited processing capabilities so any gain is valuable (as every pixel need to be converted from YCbCr to RGB and later to Amiga HW limitations).
Side to this Intra frame formats should be less intensive especially H.264 (without CABAC and deblocking loop which takes like 50 - 60% of decoder processing power).
I can made streams for testing if this is a problem.

[buggs]

Originally Posted by pandy71

MPEG-1 fully support YCgCo (just set matrix coefficient as 8 - normally it is reserved for future use in MPEG-1 and MPEG-2 but it is fully specified for H.264 and H.265 - problem is that nobody use MPEG-1 so it is uncommon practice to use YCgCo as it is not popular even nowadays but Amiga have limited processing capabilities so any gain is valuable (as every pixel need to be converted from YCbCr to RGB and later to Amiga HW limitations).
Side to this Intra frame formats should be less intensive especially H.264 (without CABAC and deblocking loop which takes like 50 - 60% of decoder processing power).
I can made streams for testing if this is a problem.

Well, the YCgCo color space is certainly appealing, not only for the lossless properties but also decorrelation abilities along with simple computation.

In terms of H.264, I'm not sure whether it would really help to save cycles on a humble 68k. Correct me if I'm wrong and missed an amendment to AMD 1, but FRExt states that YCoCg is legal only with chroma_format_idc=3, i.e. 4:4:4 and at least 9 Bit for Chroma in H.264. So when the effective pixel count doubles and 8 BPP is no longer sufficient for storage, the resulting tradeoff might well swing in an unfortunate direction (when staying standards-compliant).

[JimDrew]

The player using AMMX instructions is more than twice as fast as the version that doesn't use these instructions, using the same Vampire setup. I am not sure how much clearer this needs to be.

[meynaf]

Originally Posted by JimDrew

The player using AMMX instructions is more than twice as fast as the version that doesn't use these instructions, using the same Vampire setup. I am not sure how much clearer this needs to be.

This is valid only if the AMMX instructions are the only change between these two versions, which apparently isn't the case. Have you seen the actual code ?

[pandy71]

Originally Posted by buggs

Well, the YCgCo color space is certainly appealing, not only for the lossless properties but also decorrelation abilities along with simple computation.

It is not so popular but i see some benefits using it especially on systems without modern multimedia instructions and/or without HW processing capabilities. De-correlation chroma from luma is quite frequently noted when you read about YCgCo but somehow it is used rarely (mostly in modern desktop real time capture and compression - gaming recording etc).
Side to this i think about building OCS/ECS VIDIOT (aka Video DAC) to support HW YCgCo to RGB conversion (in AGA as external module) - it can operate on analog signal so it will be possible to remove YCgCo to RGB conversion step - maybe similar principle as Archos AVideo.

Originally Posted by buggs

In terms of H.264, I'm not sure whether it would really help to save cycles on a humble 68k. Correct me if I'm wrong and missed an amendment to AMD 1, but FRExt states that YCoCg is legal only with chroma_format_idc=3, i.e. 4:4:4 and at least 9 Bit for Chroma in H.264. So when the effective pixel count doubles and 8 BPP is no longer sufficient for storage, the resulting tradeoff might well swing in an unfortunate direction (when staying standards-compliant).

Benefits for H.264 is that it is fully integer codec - in available reports most of decoding power used for H.264 decode is: deblocking (can be turned off) and CABAC (arithmetic entropy coding) in total they can be responsible for more than 60% consumed CPU cycles - as CABAC can be replaced by CAVLC which is computationally less intense it may be case where H.264 decoder will be more efficient than MPEG-1 (offering same or better compression) and at the same time less computationally intense.

I don't see any YCgCo limitation mentioned by you - are you able to use latest official specification and confirm this?

https://www.itu.int/rec/T-REC-H.264-201602-S/en

Additionally - YCbCr is more lossy (RGB -> YCbCr -> RGB) than YCgCo -YCbCr require between 1 - 2 bits more than YCgCo to perform fully reversible RGB conversion.
Finally i would say that we should not stuck with perfect compliant decoder for Amiga - i see no problem to create Amiga optimal format based on widely accepted standards and if possible use those standards as much as possible but in Amiga every CPU cycle count so... we can anyway pre-code videos on PC (resizer quality will be always higher quality on modern CPU - Amiga probably can do real time bilinear or cubic at best without de-gamma when PC easily may precode linearized/de-gamma video with spline + something like MSAA/FXAA to reduce aliasing and improve visual quality on low res Amiga screen).

I agree - it should be standard as much as possible but to squeeze all possible cycles perhaps it is good to select subset of codec functionality to keep healthy balance between quality\speed\compatibility.

[meynaf]

Originally Posted by pandy71

Benefits for H.264 is that it is fully integer codec - in available reports most of decoding power used for H.264 decode is: deblocking (can be turned off) and CABAC (arithmetic entropy coding) in total they can be responsible for more than 60% consumed CPU cycles - as CABAC can be replaced by CAVLC which is computationally less intense it may be case where H.264 decoder will be more efficient than MPEG-1 (offering same or better compression) and at the same time less computationally intense.

That sounds very interesting, I'd like to attempt coding something in this area.
As ISO specs are difficult to find and not exactly straightforward to read, is it possible to find some reference code that would compile on Amiga ?

[buggs]

Originally Posted by pandy71

It is not so popular but i see some benefits using it especially on systems without modern multimedia instructions and/or without HW processing capabilities. De-correlation chroma from luma is quite frequently noted when you read about YCgCo but somehow it is used rarely (mostly in modern desktop real time capture and compression - gaming recording etc).
Side to this i think about building OCS/ECS VIDIOT (aka Video DAC) to support HW YCgCo to RGB conversion (in AGA as external module) - it can operate on analog signal so it will be possible to remove YCgCo to RGB conversion step - maybe similar principle as Archos AVideo.

Frankly, I see the most prominent use for YCgCo in lossless applications. At least, that was the rationale behind it's inclusion into JPEG2000, IIRC.

The idea of putting an external conversion HW to the RGB port is very nerdy, if I may say so (if not pls accept my apologies). As a side note that doesn't necessarily coincide with your particular interests, YCbCr output would work with the same approach, even leading back to the good old YUV. I'd expect some artifacts having to be addressed cleverly when thinking of colorful images by means of HAM. I'd be interested to hear about such projects going forward.

Benefits for H.264 is that it is fully integer codec - in available reports most of decoding power used for H.264 decode is: deblocking (can be turned off) and CABAC (arithmetic entropy coding) in total they can be responsible for more than 60% consumed CPU cycles - as CABAC can be replaced by CAVLC which is computationally less intense it may be case where H.264 decoder will be more efficient than MPEG-1 (offering same or better compression) and at the same time less computationally intense.

I happen to have a functional High Profile (=100) H.264 decoder on my Amiga. Please mind my wording, though. In it's current state, it's not of much use as FMV on the classic Amiga platform. It works flawlessly (bit accurate decoding) with my test suite but as of now not in the desired time frame.

I don't see any YCgCo limitation mentioned by you - are you able to use latest official specification and confirm this?
https://www.itu.int/rec/T-REC-H.264-201602-S/en
Additionally - YCbCr is more lossy (RGB -> YCbCr -> RGB) than YCgCo -YCbCr require between 1 - 2 bits more than YCgCo to perform fully reversible RGB conversion.

P.396 "matrix_coefficients equal to 8". Still unchanged in comparison to the 2004/2005 spec I had around.

The consideration towards bit depth boils down to the question whether one is able to handle the necessary bit rate where such details become truly relevant. The sheer abundance of computing power and storage capacity on the usual platforms these days allow that for interested parties, for sure. The classic Amiga is "a little" handicapped in this department (see below fo an example, please).

Finally i would say that we should not stuck with perfect compliant decoder for Amiga - i see no problem to create Amiga optimal format based on widely accepted standards and if possible use those standards as much as possible but in Amiga every CPU cycle count so... we can anyway pre-code videos on PC (resizer quality will be always higher quality on modern CPU - Amiga probably can do real time bilinear or cubic at best without de-gamma when PC easily may precode linearized/de-gamma video with spline + something like MSAA/FXAA to reduce aliasing and improve visual quality on low res Amiga screen).

I agree - it should be standard as much as possible but to squeeze all possible cycles perhaps it is good to select subset of codec functionality to keep healthy balance between quality\speed\compatibility.

The subset I'm personally aiming for (in the long run, read: not this year) is Baseline+B-Frames. This is coincidentally the same subset used by a certain popular VOD platform. In terms of H.264, I don't see much room for compromising on the algorithms. As you of course well know, H.264 was the first standard allowing (and per se demanding) bit-accurate reproduction of the bit streams and I very much honor that as IMHO the best feature of it.

At this point, my experience on a constrained platform like 68k (even the modernized interpretation that caused some stir in Amiga-land) is that you can ill afford algorithms that have become "usual" on the modern platforms.

Just today I had to step back a bit and re-calculate on performance figures. An algorithm that just takes an average 5 cycles per pixel amounts to quite some numbers when it comes to video. So when you run video in a by current standards modest resolution of 640x360, this amounts to 1152000 cycles per frame or 28.8 MHz at a desired rate of 25 FPS. Oops. My poor A500.

[meynaf]

Originally Posted by buggs

I happen to have a functional High Profile (=100) H.264 decoder on my Amiga. Please mind my wording, though. In it's current state, it's not of much use as FMV on the classic Amiga platform. It works flawlessly (bit accurate decoding) with my test suite but as of now not in the desired time frame.

That's very interesting. Could you please make it available somewhere ?