Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Performance and Benchmark Results!

Can FPGA Parallelism Help the Amiga OS?

Pak Rat

Posts 18
11 Jun 2016 01:54


I wonder how or if the 128 bit vector processor (and the other new parallel functions)in the Apollo can improve the speed/efficiency of the Amiga OS itself (with Apollo libraries replacing the originals where needed). I know that the OS is already very efficient and responsive to the user, but what sort of parallelism is possible in the FPGA that can improve (or reduce software bottlenecks of) the Amiga OS? What are some examples of obvious OS improvements that can be made?


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
11 Jun 2016 07:29


Yes this can be made.
 
Some simple examples:
 
1) Functions like Memcopy could be easily speed up
Memcopy with 800 MB/sec will be no problem.
 
2) AMIGA OS GFX functions could be speed up.
The SIMD Unit support Logical function like the AMIGA Blitter.
With something like an SIMD FBLit you could accelerate AMIGA OS GFX functions to reach speed in the range of 200 times faster than original.
 
3) RTG / Picasso96/ CyberGFX functions could be speed up a lot.
 
4) Datatypes like e.g. JPEG could be speed up a lot.
 
5) Of Course Video playback

This is just stuff that comes to mind in 1 minute...
If you think a littler longer than you think of:
CRCs used by Filesystems could be speed up a lot.
Network stacks could be speed up.
There are many possibilities.


Samuel Crow

Posts 424
11 Jun 2016 11:47


Don't forget that the integer vector support can quadruple the speed of the software mixing routines in the Paula driver on AHI.


Mr-Z EdgeOfPanic

Posts 189
11 Jun 2016 12:39


That would be big and very noticeable improvements Gunnar and also Samuel are mentioning.
The questions that rises is how much work would this be ?


Samuel Crow

Posts 424
11 Jun 2016 19:04


Don't expect wonders overnight.  AHI is simple enough to hand-compile with just an assembler as is some of the other driver support.

Trying to build a whole video decompression codec in assembly is hard though.  We're taking this step by step and trying to build development tools as we go as well.


Alan Haynes

Posts 140
12 Jun 2016 23:07


Gunnar von Boehn wrote:

Yes this can be made.
 
  Some simple examples:
 
  1) Functions like Memcopy could be easily speed up
  Memcopy with 800 MB/sec will be no problem.
 
  2) AMIGA OS GFX functions could be speed up.
  The SIMD Unit support Logical function like the AMIGA Blitter.
  With something like an SIMD FBLit you could accelerate AMIGA OS GFX functions to reach speed in the range of 200 times faster than original.
 
  3) RTG / Picasso96/ CyberGFX functions could be speed up a lot.
 
  4) Datatypes like e.g. JPEG could be speed up a lot.
 
  5) Of Course Video playback
 
  This is just stuff that comes to mind in 1 minute...
  If you think a littler longer than you think of:
  CRCs used by Filesystems could be speed up a lot.
  Network stacks could be speed up.
  There are many possibilities.

Please excuse my ignorance here but are we talking parallel FPGA's or parrallel cpu's within one FPGA?

Sounds awesome either way.

Alan from Oz


Samuel Crow

Posts 424
13 Jun 2016 01:49


Alan Haynes wrote:

Please excuse my ignorance here but are we talking parallel FPGA's or parrallel cpu's within one FPGA?

Sounds awesome either way.


Hello Alan.  SIMD means single-instruction, multiple data.  It allows an opcode in a CPU to do the same operation on multiple data elements simultaneously.  For example, streaming audio needs to perform the same operations on each sample in order so using an SIMD version of those operations allows it to process more than one sample at a time.  In fact, that's how I plan on making the Paula mixer routines faster on AHI.  The same principle applies to pixels on a chunky screen mode.

posts 7