RiVa AMMX Benchmarks

[TuKo]

Since start of the Apollo 68080 adventure, Stephen Fellner, author of the RiVa MPEG Player, was kind enough to share sources of his player with the Apollo team.

As some of you might have followed the changes in core over the last months, AMMX instructions were introduced in the Apollo-Core, meaning that software that take benefit from them experience big speedups.

With the dedicated work of buggs and flype, RiVa has been modified to take advantages from those AMMX instructions.

Here are some results :


Core: Apollo 68080 AMMX Core, Revision 3543, x11 speed
RiVa Parameters : VERBOSE NOAUDIO DISPLAY=HICOLOR NOSKIP FPS=1000

Download links :
Original RiVa
TopGun 320 Video
TopGun 640 Video

IQ has also been greatly improved (YUYV versus R5G6B5 quality) and stereo audio has also been enabled !

All this is still WIP and should be part of next GOLD2 release

Stay tuned !

[splineman]

This is very awesome!

[meynaf]

This is just empty talk without showing the actual code (both before and after).
I can get +200% and more by just rewriting compiled code into ASM, no need for AMMX.

[wawa]

I think it would be great if you joined in and contributed to make riva faster also for regular amigas.

[TuKo]

Originally Posted by meynaf

This is just empty talk without showing the actual code (both before and after).
I can get +200% and more by just rewriting compiled code into ASM, no need for AMMX.

Dear meynaf,

Thanks for your encouraging message !

We would be very happy to have your skills in team to continue the improvement. Would you like to join ?

P.S. : RiVa is already 100% ASM.

[grond]

Originally Posted by meynaf

This is just empty talk without showing the actual code (both before and after).
I can get +200% and more by just rewriting compiled code into ASM, no need for AMMX.

Why don't you optimise the original RiVa for all 68k then? I'm sure the team would be happy to give you the sources. After all they could concentrate on the spots where AMMX instructions are best used and then merge with your version of the code.

[meynaf]

Originally Posted by wawa

I think it would be great if you joined in and contributed to make riva faster also for regular amigas.

Could be nice, but I don't have RIVA sources.

Originally Posted by TuKo

We would be very happy to have your skills in team to continue the improvement. Would you like to join ?

It's some fun to read you asking me to join, as I've been an Apollo team member long before you. But major disagreements made me an 'inactive' member.

Originally Posted by TuKo

P.S. : RiVa is already 100% ASM.

Seems a little large for this. I still have to see the code anyway ; why not posting some link, or, if you don't want to make it public, send that to me by PM ?

Originally Posted by grond

Why don't you optimise the original RiVa for all 68k then? I'm sure the team would be happy to give you the sources. After all they could concentrate on the spots where AMMX instructions are best used and then merge with your version of the code.

Optimizing without having the sources is possible but quite time consuming, so it's not going to happen as long as i don't get them.

[TuKo]

Here is a screenshot of improvement on 68060 (A4000 with CS060MK-I and Cybervision 64) :



Original 0.50 on top, new at bottom

That's a 17.85% improvement. Looking forward for 200%.

[flype]

Originally Posted by meynaf

Seems a little large for this.

Hi Meynaf.

I agree. It seems little large for. But it is. I can confim you it is 100% ASM, not a single line in C - even for reading the tooltypes and command line arguments :-) It use the MPEGA.library for decoding the audio (which is also written in ASM). The full chain is ASM afaik.

The original source code, kindly shared by S. Fellner himself, is about 400KB of pure ASM (and some tables), and main file is about 15 000 lines, which is quite equivalent to the MPEGA itself.

Legacy code is already impressive and optimized ; it has been preserved even for the Apollo project and some improvements have been added in code. The work done by Buggs is a very serious one, respectful to the legacy code and brings new AMMX dedicated code but not only (68060 benefits also from the recent work). Maintaining RiVA is a serious project which needs serious 68k skills - we speak in it of all the 68k features panel, superscalar, inst/data caches, cache hits, branch predicts, accuracy of decoding, accuracy of rendering, accuracy of testings, ...

Other facts, the RiVA project compiles on my V600 in less than 8 seconds using last VASM_mot for 68000... and 68080 support. This is very acceptable compile time against a gcc project, by far. Of course 100% ASM is hardly maintainable and requires some weeks to understands.

[meynaf]

Yeah maybe, but mpega.library isn't 100% asm to start with (only critical parts were initially asm ; i got significant speedup by rewriting the huffman decoding). It's around 250-300k source (from resourced), without tables. It was compiled with SAS/C in 020+ mode (yeah i can see that when disassembling, heheh).

If RiVa isn't much bigger than mpega then it's perfectly manageable.

Now i'm wondering if old MPEG-1 is still worth the trouble, with all these MPEG-4 videos all around...

I don't believe in mmx and related stuff, and will not until i see normal handwritten asm beaten by a large amount, counting individual clocks in the routine(s). This is why i want to see the code
(i have the slight impression that i will have to repeat my last sentence a few times...)

[buggs]

Well Meynaf, you'd like to see some code? Here you go. Core loop inhorizontal interpolation as an example. Hope, the post ain't too long.

Original (core loop over two pixels, without proper rounding):

.y_xloop            move.b  (a1)+,d2        ;d2: --- --- ---  1
                        add.l   d2,d1           ;d1: --- --- --- 0+1
                        lsr.l   #1,d1           ;d1: --- --- --- 0\1
                        move.b  d1,(a2)+
                        move.b  (a1)+,d1        ;d1: --- --- ---  2
                        add.l   d1,d2           ;d2: --- --- --- 1+2
                        lsr.l   #1,d2           ;d2: --- --- --- 1\2
                        move.b  d2,(a2)+
                        dbf     d6,.y_xloop

Mine (core loop as poor man's SIMD over 8 pixels, with rounding):

                        move.l  (a1),d1 ; P00 P01 P02 P03
                         move.l 1(a1),d2        ; P01 P02 P03 P04
                         move.l d1,d3
                        or.l    d2,d3           ; P00|P01 P01|P02 P02|P03 P03|P04 -> meaning: we need to add "1" whenever any of the operands has it's LSB set
                        and.l   d6,d1           ; upper 7 bits P00 P01 P02 P03
                         and.l  d6,d2           ; upper 7 bits P01 P02 P03 P04
                         lsr.l  #1,d1           ;
                        lsr.l   #1,d2           ;
                        and.l   d0,d3           ; keep the 1
                         add.l  d1,d2           ; P00+P01 .. .. ..
                         move.l 4(a1),d1        ; P04 P05 P06 P07
                        add.l   d3,d2           ; (P00+P01+1)>>1 .. .. ..
                        move.l  5(a1),d7        ; P05 P06 P07 P08
                         move.l d2,(a2)+
                         move.l d1,d3
                        or.l    d7,d3           ; P00|P01 P01|P02 P02|P03 P03|P04 -> meaning: we need to add "1" whenever any of the operands has it's LSB set
                        and.l   d6,d1           ; upper 7 bits P00 P01 P02 P03
                         and.l  d6,d7           ; upper 7 bits P01 P02 P03 P04
                         lsr.l  #1,d1           ;
                        lsr.l   #1,d7           ;
                        and.l   d0,d3           ; keep the 1
                         add.l  d1,d7           ; P00+P01 .. .. ..
                        add.l   d3,d7           ; (P00+P01+1)>>1 .. .. ..
                         move.l d7,(a2)+

My AMMX variant, also 8 Pixels with proper rounding:

        LOADAB   1,0                 ; LOAD    (A1),B0
        PAVGd16ABB 1,1,0,1       ; PAVG.B 1(A1),B0,B1
        STOREApB 2,1                ; STORE    B1,(A2)+

You might dislike data parallelism out of whatever reasons. I respect that. But sometimes, it just comes in quite handy.

[meynaf]

Originally Posted by buggs

Well Meynaf, you'd like to see some code? Here you go. Core loop inhorizontal interpolation as an example. Hope, the post ain't too long.

Interpolation implies some kind of upsampling, and here your code writes as much data as it reads. If you've done a box filter before, you'd be better off by integrating the computation there.

This is horizontal interpolation (from jpeg decoder) - try to rewrite it with SIMD if you wish :

; a0 = input, a1 = output
; 1st row
 moveq #0,d1
 moveq #0,d0
 move.b (a0)+,d1
 move.b (a0)+,d0
 move.b d1,(a1)+
 move.l d1,d2
 add.l d2,d2
 add.l d1,d2
 add.l d0,d2
 addq.l #2,d2
 lsr.l #2,d2
 move.b d2,(a1)+
; general case
 moveq #0,d2
.xloop
 move.l d0,d3
 add.l d3,d3
 add.l d0,d3
 add.l d3,d1
 addq.l #1,d1
 lsl.l #6,d1
 move.b (a0)+,d2
 add.l d2,d3
 addq.l #2,d3
 lsr.l #2,d3
 move.b d3,d1
 move.w d1,(a1)+
 move.l d0,d1
 move.l d2,d0
 dbf d6,.xloop
; last row
 move.l d0,d2
 add.l d2,d2
 add.l d0,d2
 add.l d1,d2
 addq.l #1,d2
 lsl.l #6,d2
 move.b d0,d2
 move.w d2,(a1)+

Btw 1.
Upsampling isn't very important in the final timing.
The most important code is the DCT. As it's supposed to be done with this data parallelism stuff, well, it's that i want to see. Good luck without SIMD multiply.

Btw 2.
The parallel instructions you use here are not documented anywhere.
They just come out of nowhere and i'm supposed to trust this...

Btw 3.
You have to understand that this SIMD stuff will only work for very simple tasks. As soon as it becomes relatively complex, it starts to fail miserably - or you'll have to create new instructions for almost everything you do.
I'm not against doing things in parallel, i'm against creating new big fat registers for the sake of speed.

Btw 4.
This example can be rewritten by creating a simple longword parallel byte average instruction. One instruction added instead of a whole block, same timing if executed on two pipes.

[buggs]

Originally Posted by meynaf

Interpolation implies some kind of upsampling, and here your code writes as much data as it reads. If you've done a box filter before, you'd be better off by integrating the computation there.

Actually, I've done plenty of filtering. And I tend to avoid box filters, whenever possible btw. In case of anything from MPEG-1 to -4, however there are rules to obey. My code implements exactly what's needed to interpolate the subpixels for these standards. This is nothing else than the classic polyphase approach, where you calculate (and keep) only what you really need.

Btw 1.
Upsampling isn't very important in the final timing.
The most important code is the DCT. As it's supposed to be done with this data parallelism stuff, well, it's that i want to see. Good luck without SIMD multiply.

You know, people have been implementing ISO/IEC 23002-2 compliant DCT/iDCT algorithms with just shifts and adds. But apart from that, my recent AMMX iDCT (which sparked TuKo's post) performs parallel multiplies at full throughput just fine.

Btw 2.
The parallel instructions you use here are not documented anywhere.
They just come out of nowhere and i'm supposed to trust this...

They are documented, but as work in progress not in public. Besides, I see not much point in arguing about a necessity of trust. Take it or leave it, your choice. I just provided a code example you asked for and I'm not a marketing department.

Btw 3.
You have to understand that this SIMD stuff will only work for very simple tasks. As soon as it becomes relatively complex, it starts to fail miserably - or you'll have to create new instructions for almost everything you do.
I'm not against doing things in parallel, i'm against creating new big fat registers for the sake of speed.

Let me break it to you this way: I've been coding in SIMD since 20 years ago and tend to think that I know quite well where it applies, where not and which engineering compromises led to the trend. AMMX is not the first SIMD ISA where I've contributed the one or other thought.

Btw 4.
This example can be rewritten by creating a simple longword parallel byte average instruction. One instruction added instead of a whole block, same timing if executed on two pipes.

Yes, it can. But it wasn't the only functionality we liked to have.

[grond]

Originally Posted by meynaf

i'm against creating new big fat registers for the sake of speed.

I bet that's what they said to the guy who decided to make the D-registers 32 bit wide just like the A-registers...

[meynaf]

Originally Posted by buggs

Actually, I've done plenty of filtering. And I tend to avoid box filters, whenever possible btw. In case of anything from MPEG-1 to -4, however there are rules to obey. My code implements exactly what's needed to interpolate the subpixels for these standards. This is nothing else than the classic polyphase approach, where you calculate (and keep) only what you really need.

But the code you've shown here, is incomplete. It doesn't look like an interpolation, you're just averaging with the next value.

Originally Posted by buggs

You know, people have been implementing ISO/IEC 23002-2 compliant DCT/iDCT algorithms with just shifts and adds. But apart from that, my recent AMMX iDCT (which sparked TuKo's post) performs parallel multiplies at full throughput just fine.

I want to see the code. I've touched several DCT and none had any spot to perform anything in parallel.

Originally Posted by buggs

They are documented, but as work in progress not in public. Besides, I see not much point in arguing about a necessity of trust. Take it or leave it, your choice. I just provided a code example you asked for and I'm not a marketing department.

If this is just a work in progress and not publicly available, why creating a thread to boast about its performance here ? Isn't it selling the fur before killing the beast ?

Originally Posted by buggs

Let me break it to you this way: I've been coding in SIMD since 20 years ago and tend to think that I know quite well where it applies, where not and which engineering compromises led to the trend. AMMX is not the first SIMD ISA where I've contributed the one or other thought.

So if you know quite well, just explain.

Originally Posted by buggs

Yes, it can. But it wasn't the only functionality we liked to have.

Then i may eventually want to see another of these functionalities in action, huh ?

Originally Posted by grond

I bet that's what they said to the guy who decided to make the D-registers 32 bit wide just like the A-registers...

Perhaps there is a good reason for this...

[grond]

Originally Posted by meynaf

Perhaps there is a good reason for this...

Probably the same good reason that Intel keeps ignoring while doing new SSE-versions every other year...

So what are your reasons? If a few ammx instructions can speed up movie replaying by a factor of two, they must be very convincing reasons.

[meynaf]

Originally Posted by grond

Probably the same good reason that Intel keeps ignoring while doing new SSE-versions every other year...

Fine. So people start using their extensions and they become obsolete every other year - anything that's fine doesn't have to get replaced at that pace.
But you can't compare. Intel throw massive amount of logic gates at every problem they face. There is also a good reason why their cpus don't go in handheld devices.

Originally Posted by grond

So what are your reasons? If a few ammx instructions can speed up movie replaying by a factor of two, they must be very convincing reasons.

Speed up movie replaying by a factor of two isn't a good enough reason to build frankenstein-like extensions, especially when it can be done otherwise.
What is movie replaying anyway ? Old MPEG-1 ? You can't show youtube videos with that. Play them with your smartphone : they won't use any mmx-like extensions - they'll use a gpu.

So perhaps a few ammx extensions can make better performance in a single example. One can always invent new instructions for a particular case. But next program you do, new ammx extensions will be needed.
All that for a miserable x2 speed on something that's not used anymore.

I have disassembled Riva and seen that this is indeed asm code, but the guy apparently "played compiler" ; it seems the original code has been followed without much refactoring.
For example, the DCT shifts the result back too early after the multiplies, leading to a loss of speed (unneeded shifts) and loss of quality (reduced accuracy).
There is also a lot of duplicated code (if not dead code).
In short it's not exactly nice - not surprising a few code rewrite got a speedup. Again, mmx isn't needed for that.

[grond]

Since you know how to do it so much better: when will see your non-ammx version of the code beating the ammx-version?

[meynaf]

Originally Posted by grond

Since you know how to do it so much better: when will see your non-ammx version of the code beating the ammx-version?

Maybe when that thing will be available to get somewhere ?

Anyways the "ammx version" doesn't need my code to be beaten :

4.Upload:> riva-0.50 verbose fps=1000 noskip noaudio dither=gray shk_topgun_320.mpg

 Video: 320x176, 24.000 fps
 Audio: <NONE>

 Number of frames played:  2143
 Number of frames skipped: 0
 Total number of frames:   2143

 Total playback time: 13.1146 seconds.
 Average framerate:   163.4048 fps
 Displayed framerate: 163.4048 fps

4.Upload:>

Where's the point ? If we want speed, we can already have it with legacy instructions.

[grond]

Originally Posted by meynaf

4.Upload:> riva-0.50 verbose fps=1000 noskip noaudio dither=gray shk_topgun_320.mpg

Where's the point ? If we want speed, we can already have it with legacy instructions.

You probably also use "cat" as a video player on linux, so many fps!

BTW, the fact that you had to use the dither=gray option to make your UAE beat the 080 proves two points: AMMX is a very powerful extension to the 68k ISA and you need to buy a newer PC.