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
The team will post updates and news about our project here

SAGA / AGA Launchpage  1 2 3 4 5 6 7 8 9 10 11 

Mallagan Bellator

Posts 393
09 Jun 2018 11:52


David Wright wrote:

I like Gunnar's computer parables. An Amiga digital messiah.

I love the way he compares the computer world to real world issues, and makes it sound just as obvious as it really is xD
A true master at explaining stuff to someone who doesn’t know squat!
Let’s all kneel and pray to the all mighty Gunnar!


Louis Dias
(Needs Verification)
Posts 55/ 1
10 Jun 2018 05:18


Yes, but now picture a SuperAkiko that can contains 256 cores of the current one.  That's why GPU's give you - parallel computing power.

EXTERNAL LINK  Notice how the Akiko optimized version of Doom increased the framerate greatly over the A1200 version.

Yes, the 080 is much faster than the 020, but why shouldn't the Akiko not get Vampirized as well?  However, I would not limit it to C2P, I would add multiple AMMX cores to it so it could work on an array of 256(or 512...or heck 1024) vertices at once.



Stefano Briccolani

Posts 586
10 Jun 2018 06:47


Gunnar said that "Using AKIKO has HUGE communication overhead" and that implementation will cost time and probably slow down the entire system. The point is: implementing the Akiko chip is complete waste of time..you can have better 3d in vampire without re-implementig that chip


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
10 Jun 2018 07:50


Louis Dias wrote:

Notice how the Akiko optimized version of Doom increased the framerate greatly over the A1200 version.

Yes, the 080 is much faster than the 020, but why shouldn't the Akiko not get Vampirized as well?

I sense that you misunderstand how AKIKO works.
As I did develop an AKIKA let me tell you how it worked.
AKIKO can not access memory, AKIKO can not execute instructions.
AKIKO does only 1 logic operation.
To use AKIKO the CPU needs to push data into AKIKO and pull out the data from it.

Sorry to talk technical now, I hope all can follow I will try to simplify it .
Example:

Lets look at the C2P instruction.
The C2P instructions reorders bits.

Lets now say executing 1 instruction takes 1 cycle for a CPU with fastmem and cost 2 cycle for a CPU without fastmem.

So doing the C2P operation with fastmem would cost 1.
Doing the C2P operation without fastmem would cast 2.

Lets now say your CPU does not have this C2P instruction
but could emulate it internally by doing 32 instructions.

So your program to emulate CP2 is 32 instructions.
So emulating C2P has a cost of 32*1 == 32 cycle if you have fastmem.
And in the CD32 without fastmem it costs 32x2 == 64 cycle.

Now AKIKO offer this C2P in HW - but to use it the CPU needs to WRITE the input first into AKIKO and then read it back.
To use AKIKO the CPU needs to do 8 WRITE and then 8 READ.
As AKIKO is external the cost to WRITE to it is always 2 and read from it is also always 2.
This means doing the work with using AKIKO has a cost 16*2 == 32

In our example:


COST
    1  CPU with C2P instruction and fastmem            == APOLLO
  64  CD32 without this instruction and without fastmem
  32  CD32 using AKIKO

Is it clear to you now that APOLLO 68080 is always magnitudes faster than using AKIKO?


Markus B

Posts 209
10 Jun 2018 07:54


Louis Dias wrote:

Yes, but now picture a SuperAkiko that can contains 256 cores of the current one.  That's why GPU's give you - parallel computing power.
 
  EXTERNAL LINK  Notice how the Akiko optimized version of Doom increased the framerate greatly over the A1200 version.
 
 
  Yes, the 080 is much faster than the 020, but why shouldn't the Akiko not get Vampirized as well?  However, I would not limit it to C2P, I would add multiple AMMX cores to it so it could work on an array of 256(or 512...or heck 1024) vertices at once.
 

Akiko's main function, C2P conversion, can be handled by an AMMX instruction, so no need for an extra core for this function.

I doubt that this conversion can be done quicker by splitting into multple smaller parts and invoking multiple AMMX cores. I assume the overhead simply kills it.
This may be different for more complex 3D calculations where it makes sense to compute results in parallel.

Of course, happy to hear Gunnar's point of view.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
10 Jun 2018 08:03


Markus B wrote:

This may be different for more complex 3D calculations where it makes sense to compute results in parallel.
   
Of course, happy to hear Gunnar's point of view.

 
I understand your point or question is "more people can do more work".
This sounds obvious.
 
So working in a team of 2 you can assume to be able to do more work.
 
But lets make a real world example.
Lets say you work in a project in a team of 2 people with colleague over sea.
Lets say you are in the states and you speak only English
and your partner who works with you is in CHINA and speaks only chinese.
 
While you have now a team of 2 - you also have significant communication overhead - every sentence you say you have to online translate first. And as you two live in different time zone communication takes significant effort.
 
How much easier would it be to work with a colleague in the same office where both speak the same language?
 
 
This real world example is very similar to having a CPU and an external GFX chip - which both are far apart and speak different languages.
While having 2 CPU cores - which both are very close and speak the same language would have much less communication overhead.
 
If you CPU is a competent worker by itself,
then a very efficient way to increase performance is to add a 2nd CPU core.
 
APOLLO 68080 is highly powerful by itself and APOLLO 68080 is internally designed with Multi-Core support.
 
 


Thellier Alain

Posts 141
10 Jun 2018 08:34


I will also add this:
Why still use a c2p routine on a vampire as it got reals chunky 8/16/32 bits screen mode

I think most non-coders people think Akiko do (some kinda) 3d but no it only convert some pixels to another format


Stefano Briccolani

Posts 586
10 Jun 2018 09:56


This thread is becoming an Amiga masterclass! Gunnar's replies are sort of wisdom pearls..


Tango One

Posts 102
10 Jun 2018 13:39


Gunnar von Boehn wrote:

 
  So working in a team of 2 you can assume to be able to do more work.
   

Thats awsome of what this team have done in so short time, compared to what C= did with some thousends of employees.



Louis Dias
(Needs Verification)
Posts 55/ 1
10 Jun 2018 17:02


I think you guys are getting hung up on the C2P routine itself.  I was referring to it as an example of speeding up something the cpu doesn't need to waste it's time with...
We are talking about 3D here.  Let's talk about triangles...
A triangle contains 3 vertices.  Those 3 Vertices have an X, Y and Z value.  Hence to move and rotate a triangle[polygon], you have to execute 18 instructions and 9 of those instructions involve sine/cosine...
Consoles of the mid-90's were pushing 200,000 textured and shaded polygons at 30fps.

Perhaps, the Akiko is the wrong place for these types of functions.  Perhaps the *COPPER* could be expanded to include parallel-processing AMMX functionality.  Remember, with 3D you want to transform at least 256 vertices at a time (1024 would be even better), not maybe 4 or you'll never have the framerate required for functional good-looking 3D games.  With PCs, I know *dirty word* the GPU has it's own memory.

Since the '080 has plenty of cache, would be possible to allow the Copper full cycle access to memory temporarily so it could load a chunk of memory into it's internal memory to perform these millions of calculations?  Then when done, request full control again to dump the results back?  The best part of this is if the COPPER was linked to it's own memory sockets where the user could decide how much COPPER RAM they had for 3D functionality.

Obviously, this would be for a newer Apollo core.  I see the feature-set of the current one is well defined and that is what needs to get out the door.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
10 Jun 2018 17:53


Louis Dias wrote:

Consoles of the mid-90's were pushing ...

If APOLLO could not do this too, then coming up with proposals would make sense - but as APOLLO can do this too - those proposals make hardly any sense.



Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
10 Jun 2018 18:13


Gunnar von Boehn wrote:

 
    If APOLLO could not do this too, then coming up with proposals would make sense - but as APOLLO can do this too - those proposals make hardly any sense.
   
 

 
  Well, major difference is currently Gunnar has V4 Vamps, supposedly with more cache, even faster memory, more RAM and I suppose a bit higher frequency. One in all, that is full current potential of Vampire.
 
  Surely, Aikiko is adequate but for 020. V4 leftover space could be used for some form of 3D acceleration. I would be good if e.g. any form of Voodo could be licensed from 3Dfx (nVIDIA?), since it enjoys some level of support under OS3. Or Radeon 7000-9000 series (AMD?) to that matter. And is well known to 3D coders worldwide.
 
  I have no idea is it feasable, but would complete circle of both SAGA and 3D, if that is the point.


Samuel Crow

Posts 424
10 Jun 2018 20:02


Re:3d support
Walk before you run.  Let's bury multicore ARM SoC machines before trying to take on desktop machines.  Remember that the 68080 is only an Atom class SoC at this time.  If we had a 680x0 CPU that was comparable to an Intel i-series chip but had no 3d drivers for it, it would be pointless.  AmigaOS doesn't even come with Mesa, let alone Vulkan-class drivers.  Mac has already deprecated OpenGL and OpenCL in the latest version of macOS in favor of its homegrown Metal 2 drivers.

Let's use the AMMX unit we have before looking to add what may be expensive circuits.  Thanks to bitcoin mining, high-end graphics cards are difficult to afford.  I want a Vampire myself before you hyperinflate the cost of production to the point at which I'll never afford one.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
10 Jun 2018 21:01


Samuel Crow wrote:

  Let's use the AMMX unit we have before looking to add what may be expensive circuits.  Thanks to bitcoin mining, high-end graphics cards are difficult to afford.  I want a Vampire myself before you hyperinflate the cost of production to the point at which I'll never afford one.
 

 
  Agreed. But even MiniGL-tinyGL/90s MESA drivers are better then none. If once possible, (e.g. ASIC, even larger FPGA) I assume licensing old RV200 or Voodo tech could be not so expensive, and that could be Amiga compatibile 3D solution. Not much but up to last Amiga machines, 90s consoles and first era of 3D accel. PCs.

What about using CPU to drive Warp3D (Wazp3D)? Could that be AMMX optimized, and would be sufficient for time being.
 
  There is Amiga 3D without Warp3D. On the Amiga demo side could you display Tornado 3D and Vista generator on v4/AGA v2


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
10 Jun 2018 21:05


Vojin Vidanovic wrote:

I assume licensing old Voodo tech could be not so expensive, and that could be Amiga compatibile 3D solution.

Please mind:

Voodoo can do a lot less than AMMX.
Voodoo is 16bit - AMMX is truecolor.
AMMX supports compressed texture formats - Voodoo does not support them.
AMMX is flexible and freely programmable - Voodoo is not.
And if put in an FPGA, then your Voodoo is not faster than AMMX at all.



Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
10 Jun 2018 21:23


AMMX is flexible and freely programmable - Voodoo is not.
    And if put in an FPGA, then your Voodoo is not faster than AMMX at all.

 
  While most is true for Voodo 1-3, its not for 4-5 (VSA100) or crazy 3Dfx Rampage (closer to nv20). I do understand its not best possible solution, just easy one.
 
  If AMMX can be used to 3D accel. Warp3D first and some other OpenGL like solution in AROS or similar, I am very much glad about it and will cease nagging about 3D for lifetime.
 
  Just for the sidenote, most interesting 3D chip to me was 3D Labs GLINT a real pioneer in OpenGL :-) I wonder since we have Parmedia 2 compatibility thanks to Phase 5, could that be a solution?



Andy Hearn

Posts 374
14 Jun 2018 10:32


yeah while I loved the idea of the 3Dlabs architecture, it's just a shame that "consumer level" permedia2 cards sucked so badly because they didn't have the triangle setup engine the pro level boards with the GLiNT chips provided the 1st generation of the permedia chipset IIRC

I think an AMMX wrapper/driver for Warp3D, or Warzp3D(?) would be an amazing first step - as my understanding is that bilinear filtering can be executed efficiently in the Apollo core, and I would imagine scene setup and texturing isn't far behind either.

ideally to my mind, the path would be to create new drivers for existing platforms and APIs, and then you're not having to re-port existing 3D engines and content.

However I do see a lot of this 3D hardware chat as a "running before walking" situation. a bit "let's daydream" - but then that's how the vampire came into being in the first place... :D


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
14 Jun 2018 12:29


AMIGA high resolution real time 24bit texture mapping done with AMMX

EXTERNAL LINK


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
14 Jun 2018 14:03


Gunnar von Boehn wrote:

  AMIGA high resolution real time 24bit texture mapping done with AMMX
 

 
  Demo (as well as Jubimark scores) is impressive and it will be interesting to see how much V4 will push the limit with higher freq, more cache, more/faster RAM/even faster FPU ...
 
  On the 3D SAGA "front" it would be most impressive to have even alpha version of Wazp3D for 080-AMMX. If anything can be offloaded to new Blitter during CPU intensive 3D emulation, the better.
 
  Count it as enabling last part of 68k AmigaOS 3.x software/few games to work on Vamps. And enabling use of existing 3d layer.
 
 
  I see MesaGL 3.0 was last port no requiring real 3D card
  EXTERNAL LINK   
  Warp3D could offer StormMESA compatibility, which wasnt much used during the Classics, but Vamp could give it a chance?
  EXTERNAL LINK 
  StormMESA seems to have NOHW:
  Forces the graphics to be drawn by the CPU, the 3D
  hardware is not touched.


Thellier Alain

Posts 141
14 Jun 2018 17:06


Wazp3D for AMMX was already discussed here

CLICK HERE

posts 220page  1 2 3 4 5 6 7 8 9 10 11