Demo Coder Challenge - Vampire Beta Project !

[Gunnar]

Hi,

We prepare a new CPU load for the Vampire.
This CPU load is relative fast.

In addition to this, the CPU has some unique features.
If clever used you can get __really__ good performance with them.
As with every CPU to use to to the maximum a skillfull code is needed. :-D

I'm looking for some interested ASM coders which like to beta-test
the core and which like to create some demos for it - which really push it to the limit.

In theory a demo could of course also be coded without having access to a Vampire yourself.
But to be able to later beta-test the core a Vampire card would be usefull.


Please ping me if you are interested.

[cgugl]

So the phoenix core for the vampire 600 is ready and functional?

I offer myself to try on my amiga !

[Gunnar]

Originally Posted by cgugl

So the phoenix core for the vampire 600 is ready and functional?

I offer myself to try on my amiga !

The core is working - but not all instructions are tested yet.
This will take time to test all.
This month you can NOT expect to just run any Amiga game.

But nevertheless you can savely write programs which use the tested instructions.
Your programs will work correctly.

This way you could write stuff like 4K demos which work both correct and fast.
You could "load" those demos into the card and you could execute them.


It would be nice to create some demos which really challenge the core.
Maybe a high quality texture mapper, or a real time fractal generator.
The more CPU challenging the better

Like writing the "Juggler demo" but maybe this time rendered in real time :-D


If you like to code som ASM demos.
First maybe small ones ...
To help to test and benchmark the core then this help would be appreciated.

I will provide a complete list of available instructions, timings, and special features that can be used.

Cheers

[pandy71]

Secrets, mysteries, x-files... lol - not being a coder i'm curious about those new features - any chance to less secrets? (ignore this message if this is commercial product then no need to explain why is so secret)

[Gunnar]

Originally Posted by pandy71

Secrets, mysteries, x-files... lol - not being a coder i'm curious about those new features - any chance to less secrets? (ignore this message if this is commercial product then no need to explain why is so secret)

Documented will be available when the core is out.
Until then features could still come in / or out.

[robinsonb5]

Can you at least "whet the appetite" with an example or two of what special tricks this core has up its sleeve?

[cgugl]

unfortunately I do not know the ASM ...

I'd like to know if with this core You can now boot and start the workbench...

[pandy71]

Originally Posted by Gunnar

Documented will be available when the core is out.
Until then features could still come in / or out.

This is my point - perhaps features can be added/removed/modified before finalizing documentation and development - after this it can be to late.

[britelite]

Originally Posted by Gunnar

I will provide a complete list of available instructions, timings, and special features that can be used.

Will you also provide tools, like a compiler and emulator?

[Gunnar]

Originally Posted by britelite

Will you also provide tools, like a compiler and emulator?

The CPU is an 68K CPU, therefore normal AMIGA development tools all work.
This means you can write a normal demo which can run both on any classic AMIGA and on Phoenix/Vampire.

The CPU can be emulated in a VHDL development tool (e.g. Modelsim or Cadence). This is might be useful for analysis of certain high performance loops - as you can this way see a lot of internal information like Cache-misses, Memory-Prefetches etc.
So if you write for example a texture mapper and wonder if there might be options to tune the code then I can analyse the workloop and create a pipeline diagram showing you bubbles or options to tune the code,

[TCD]

Originally Posted by Gunnar

In addition to this, the CPU has some unique features.

Originally Posted by Gunnar

The CPU is an 68K CPU, therefore normal AMIGA development tools all work.

Does not compute.

[britelite]

Originally Posted by Gunnar

The CPU is an 68K CPU, therefore normal AMIGA development tools all work.
This means you can write a normal demo which can run both on any classic AMIGA and on Phoenix/Vampire.

If it's only a 68k cpu without any additional instructions, then I don't think it's worth the hassle to rewrite my current texture mappers (or any other demo effects).

So, for testing you could just use current 060 demos and see if they run at a better frame rate

[Gunnar]

Originally Posted by britelite

If it's only a 68k cpu without any additional instructions, then I don't think it's worth the hassle to rewrite my current texture mappers (or any other demo effects).

So, for testing you could just use current 060 demos and see if they run at a better frame rate

Well, the core is integer only as an FPU does not fit into FPGA.
Is your texture mapper integer code only?

How do you calculate the texture coordinates, do render lines with constant distant to the viewer and therefore only "add-up" texture coordinates. Or do you render next pixels on the screen and either have to cheat on the exact texture coordinate or do you use a DIV/SQRT per pixel?

Is your texture rendering loop already unrolled to be able to take part of OoO CPU features?

How do you do the C2P conversion?
Do you use a seperate task for this which could be ran as hyperthread easily?

[britelite]

Originally Posted by Gunnar

Well, the core is integer only as an FPU does not fit into FPGA.
Is your texture mapper integer code only?

All my linear mappers are integer only, my perspective mapper uses fpu.

Unless the new core adds some useful new instructions, there's no point in rewriting the texture mappers if there's a risk it will lead it to perform worse on an 060.

[Gunnar]

Originally Posted by britelite

All my linear mappers are integer only, my perspective mapper uses fpu.

Unless the new core adds some useful new instructions, there's no point in rewriting the texture mappers if there's a risk it will lead it to perform worse on an 060.

The linear mapper render from left to right on the screen or left to right in the texture?
Is the perspective for the linear corrected of some pixels or never?

What would you say is the buiggest "bottle" neck on the 68060?
Is it CPU power, or is it memory latency /bandwidth?

[britelite]

Originally Posted by Gunnar

Is the perspective for the linear corrected of some pixels or never?

It's linear, so it's not perspective corrected

What would you say is the buiggest "bottle" neck on the 68060?

For linear texture mappers it's definitely memory speed.

[Gunnar]

Originally Posted by britelite

It's linear, so it's not perspective corrected

For linear texture mappers it's definitely memory speed.

Lets say a memory read would nto block the CPU, but it could continue to execute independant instructions.
E.g for example you calc to pixel im parallel and when one does the memory read you do the color/light mixing of the other. This way the memory latency would be 100% hidden and your texture fetch is only 1 cycle.

Would you say this would improve perfromance a lot?


Are sources of your routines available somewhere?

[pandy71]

Aaaah i see your point now - from my side two proposals (sadly - not like you expecting) - perhaps something like RPTx from TMS320 can be added (repeat single and repeat block) this should be not resource intense, i would go also for real barrel shifter maybe increase twice amount of registers (two banks, fast context switching), probably also MAC instruction can be nice to have (perhaps coprocessor interface similar to 68882?)

[Gunnar]

I think a good coder could do on the Vampire/A600 something like:

real time fractal renderer which runs in :
Hires-Interlaced 640x480 with 16 colors and 60 FPS
Ah no does not work - we can not get the other halve of the bus bandwidht

Thats a pity we have a fast CPU but the chipset still limits our options.

The best options for display that I see are running somehting like
Lowres EHB for games in 25 FPS.
This should work fine.

[britelite]

Originally Posted by Gunnar

I think a good coder could do on the Vampire/A600 something like:

real time fractal renderer which runs in :
Hires-Interlaced 640x480 with 16 colors and 60 FPS

Oh really, does the Vampire also speed up the chipmem-access?