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
Running OCS/AGA/RTG Demos

Playing Around With High Quality Texture Mappingpage  1 2 

Gunnar von Boehn
(Apollo Team Member)
Posts 6207
13 Dec 2017 11:11


thellier alain wrote:

So it still need much cycles : something like 4 x DTX1 and 3 X PIXMRG ...

Obviously it needs several cycles.
The operation does several Memory/Cache operations, therefore it by nature will have to need several cycles.

thellier alain wrote:

A builtin AMMX function like ARGB=GetFilteredTexel(tex,u,v); will be more usefull

Don't confuse routines with ASM instructions.
Having macro ASM instruction taking several cycles would not be good. The best solution is having key element instructions in ASM, which allow you to solve big problem by putting several ASM instructions together.

 
thellier alain wrote:

Also not all textures are DXT1 format nor RGB only : I mean reading a standardized ARGB texel from any format will be much more usefull
Same apply for writing pixels

Programming is done in layers.
The CPU has to provide the Key-elements.
On top of those you build routines
On top of those you build libraries,
on top of those you can build applications or programs.

The optimal CPU gives you powerful key elements - which execute fast.

Lets make some clearer examples.
The 68K architecture offers powerful "key-element" instructions like:
  MUL for doing a MULTIPLICATION,
  DBRA for doing a Decrementing of a counter, Comparing, and Looping

The goal is to make those powerful key functions fast.
68080 for example does a DBRA instruction in 0.5 cycles.
This is optimal.

Some RISC CPUs lack such powerful key instruction and need several instructions and several cycles to do the same. This makes these RISC CPUs cheaper, but also weaker.

The point of AMMX is to offer re-usable and extremely powerful instruction -  which execute each in 1 cycle each or less.
So having a PIXMRG instruction which executes in 0.5 cycles is optimal. You can combine several of those in your programs to solve bigger problems. This gives to programmer to flexibility so solve many problems and to decide which solution the programmer prefer to have.

Apollo AMMX offers very powerful Key-Element instructions.
Single ASM instruction to uncompressing 1 RGB texel
Single ASM instruction to ALPHA Blend texels.
Single ASM instruction to convert color formats.

You can combine those instructions to solve many different problems.
The programmer has the freedom to run in the screen in HICOLOR, TRUECOLOR, or ARGB.
The programmer can decide to run DIRECT MAPPING, BI-Linear Filtered, TRI-Linear Filtered.



Gregthe Canuck

Posts 274
13 Dec 2017 14:20



Gunnar you are bang on - you have to start at the bottom and get the basics right with the CPU/AMMX and build on that.

In the far future I can see the possibility of building a basic 3D graphics core out of multiple chopped-down 68080 cores. How cool would that be? This is just a fantasy for now and I am sure you have had that discussion already in the team. ;)

Cheers!


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
13 Dec 2017 15:04


gregthe canuck wrote:

In the far future I can see the possibility of building a basic 3D graphics core out of multiple chopped-down 68080 cores. How cool would that be? This is just a fantasy for now and I am sure you have had that discussion already in the team. ;)

INTEL Team would call this LARRABEE.  ;-)

The AMMX texture instructions give us pretty good texture power now.
The visual quality of these operations is very high, with better quality than VOODOO GFX Cards.

As near goal, I see some low poly game options.
As long term goal, looking forward to an APOLLO ASIC,
I see games like QUAKE3 or above PS2 game level.


Thierry Atheist

Posts 644
13 Dec 2017 17:31


Hi Simo Koivukoski,

For some reason there is a red triangle in the upper left hand corner throughout the whole video.

Otherwise, I am SPEECHLESS!!!!!!!!

SO exceeds ANYTHING I could have hoped for, in regards to genuine AMIGA progress!!!!!


Simo Koivukoski
(Apollo Team Member)
Posts 601
13 Dec 2017 17:43


Thierry Atheist wrote:
For some reason there is a red triangle in the upper left hand corner throughout the whole video.

Don't worry, it's hardware mouse cursor. On final showcase it can be hidden.



Mallagan Bellator

Posts 393
13 Dec 2017 23:20


Gunnar von Boehn wrote:

Little update
 
  Video:
 
  CLICK HERE 
  The above video uses compressed textures.
  In real time the texels are decompressed and bilinear filtered to create calculate screen.
 
  Screen resolution is 640 Width.
  Screen bitdepth is 16bit HICOLOR
 
  The ASM rasterizer loop was tuned to be benefit from Super-Scalar and Fusing better, as you can see framerate is very smooth now.

oohhh, that is one foxy animation! ;) me like!


Mallagan Bellator

Posts 393
13 Dec 2017 23:25


Gunnar von Boehn wrote:

  On the 68080 I use for this demo some new instructions - this help a lot to make it both look good and run faster.
 
  But wrote the current raster texture code in 2 days.
  There is certainly more room for improvement and tuning.
  I'm sure the code can run 25% faster if better tuned.

it's still good. of course it can be improved, while the program is still so young, there's always room for improvement! ;)


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
14 Dec 2017 02:29


Small update.
We changed the demo to render the whole screen in truecolor 32bit.
This was a great idea, the demo looks real amazing now.

Also the raster code got a little faster.
The code is better scheduled now and executes 2.1 instructions per cycle.

So its good looking and fast :-)

Simply amazing what demos an A500 can do.




Mallagan Bellator

Posts 393
14 Dec 2017 02:53


that's amazing Gunnar, you should make a new video!


Kef Emzy

Posts 50
14 Dec 2017 05:23


Gunnar von Boehn wrote:

  Small update.
    We changed the demo to render the whole screen in truecolor 32bit.

 
Hi Gunnar, is there a big difference in speed vs 16 bit?
 
 


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
14 Dec 2017 11:29


Kef Emzy wrote:

  Hi Gunnar, is there a big difference in speed vs 16 bit?
 


 
  Rendering in full Truecolor or Rendering in 16bit has the same speed.
  But Truecolor does look better.
 


Kef Emzy

Posts 50
14 Dec 2017 13:52


Gunnar von Boehn wrote:

  Rendering in full Truecolor or Rendering in 16bit has the same speed.
  But Truecolor does look better.
 

Truecolor has a tendency to do so yes. ;)

Anyway, I get the point. Whatever speed difference there is, it's negligible.



Thierry Atheist

Posts 644
14 Dec 2017 22:24


Simo Koivukoski wrote:
Thierry Atheist wrote:
For some reason there is a red triangle in the upper left hand corner throughout the whole video.

Don't worry, it's hardware mouse cursor. On final showcase it can be hidden.

Hi Simo,

Oh, now I understand. I saw a reference to it earlier, and it didn't click in my mind because "block" was mentioned and I saw a triangle.

This is SIMPLY AMAZING!!!!!!

posts 33page  1 2