3D - F030 vs Amiga 1200

All about demos on the Falcon, TT & clones

Moderators: Mug UK, [ProToS], lp, moondog/.tSCc., Moderator Team

User avatar
nativ
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4106
Joined: Mon Jul 30, 2007 10:26 am
Location: South West, UK

Re: 3D - F030 vs Amiga 1200

Post by nativ »

Vision - Oxygene (1995)
http://www.youtube.com/watch?v=xFO7bWcCRCA
how they made scene at 3:40 ???

3d generated mono video with colour temp change?
Atari STFM 512 / STe 4MB / Mega ST+DSP / Falcon 4MB 16Mhz 68882 - DVD/CDRW/ZIP/DAT - FDI / Jaguar / Lynx 1&2 / 7800 / 2600 / XE 130+SD Card // Sega Dreamcast / Mega2+CD2 // Apple G4

http://soundcloud.com/nativ ~ http://soundcloud.com/nativ-1 ~ http://soundcloud.com/knot_music
http://soundcloud.com/push-sounds ~ http://soundcloud.com/push-records
EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 894
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK

Re: 3D - F030 vs Amiga 1200

Post by EvilFranky »

calimero wrote:
EvilFranky wrote:For the record I don't consider an A1200 with FASTRAM stock :)
nether do I consider A1200 with FASTRAM stock but almost all demos require at least fastram and beside, fastram was not expensive to add - it will just cover cost difference between F030 and A1200 :) and with FastRAM Amiga architecture will have meaning! (on Falcon, you need a entire turbo card - CT2 or AB40 - to got a fastram)
If that is what you feel then fine, but I don't agree.

Stock for stock in my opinion, regardless of cost! I didn't know you could buy a FASTRAM card for £100 back in 1992/3 as I never paid attention to Amiga hardware.
EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 894
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK

Re: 3D - F030 vs Amiga 1200

Post by EvilFranky »

Are You Experienced? by EKO - Stock Falcon

http://pouet.net/prod.php?which=1180
EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 894
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK

Re: 3D - F030 vs Amiga 1200

Post by EvilFranky »

eko system by EKO - Stock Falcon

http://pouet.net/prod.php?which=8572
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2378
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: 3D - F030 vs Amiga 1200

Post by calimero »

EvilFranky wrote:eko system by EKO - Stock Falcon

http://pouet.net/prod.php?which=8572
EKO, as EXA, have great polygon count in flat 3D scenes! (plus - great gouraud shadin, maybe the best on falcon!)

but there are more complex 3D scenes with textures in other demos...
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
shoggoth
Nature
Nature
Posts: 1017
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: 3D - F030 vs Amiga 1200

Post by shoggoth »

calimero wrote:but there are more complex 3D scenes with textures in other demos...
Hmmm and Underscore by Escape have some great gouraud shaded3D in them imo.
Ain't no space like PeP-space.
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2378
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: 3D - F030 vs Amiga 1200

Post by calimero »

shoggoth wrote:
calimero wrote:but there are more complex 3D scenes with textures in other demos...
Hmmm and Underscore by Escape have some great gouraud shaded3D in them imo.
^ better than Eko/Exa but they are 5-6 years newer :)
beside, in Escape demos you have only texture mapped 3D objects!
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2378
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: 3D - F030 vs Amiga 1200

Post by calimero »

dml wrote: Mikro has probably measured this. I've been working mainly in relative terms so I didn't check bandwidth and write down numbers. Pretty fast though - approaching (but not quite) the same as copying from STRam.
first, thanx for replay! :)

but how is it possible to achieve ST Ram speed when ST Ram bus is 16bit and 16MHz while DSP is 8 bit and 16MHz (?), right?
dml wrote: You can do everything on the DSP, except direct access to large datasets (DSP has 96kbyte - if it fits in 96kbyte then you need CPU only for copying/plotting dots on the screen)
that is cool but if DSP could render entire screen than you have another problem:
you can not fit entire frame (video) buffer to 96KB - 320x200x16bit is 128KB!
so you need to copy data from DSP Ram to ST Ram before VBL is over?!?
plus, you need to upload all new data for next frame?
dml wrote:... fit for that frame). The bottleneck and space problems need very careful management.

I have at least 3 different systems on DSP already (most complex being BMEngine) and they all work very differently.
interestingly, so DSP works almost as GPU/SIMD in modern day computers? :)
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 894
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK

Re: 3D - F030 vs Amiga 1200

Post by EvilFranky »

Reading that EAB forum post...

What on earth is that pandy71 user going on about? Falcon and A1200 can not be compared?

They were each companies respective 32-bit venture into the affordable home computer market, they were essentially direct competitors :roll:
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2378
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: 3D - F030 vs Amiga 1200

Post by calimero »

^
I do not know. If I continue to replay to him, he will never stop with nonsense... :/
calimero wrote: - I know that Mikro/Mystic Bytes made 3D engine on DSP where textures are also stored and calculated on DSP.
- does anybody elso done this?
I just read on Norman Feske (NO/Escape) web site:
My most adventurous and most exciting coding experience so far was creating a 3D engine that runs completely on a DSP56001. The primary motivation for doing this was to create cool and fast demo effects on the Atari Falcon. On this machine, built in the year 1992, the DSP, originally intended for audio processing, clearly outperforms the MC68030 CPU in terms of raw computational power.

First, I created a small operating system for managing the control flow inside the DSP from the host and for loading new code and data into the DSP while the audio mixer (running in the DSP interrupt context) continues to play music. Then I started doing 3D transformations, polygon sorting, clipping, scanline rendering, and finally real-time 3D model generation (e.g., a fractal tree, morphing 3D IFS fractals) directly on the DSP (some examples). Later, I experimented with using the DSP's 32Kword memory as frame buffer and applying 2D postprocessing (e.g., real-time blur with varying filter size, feedback effects) onto the result of the 3D renderer and performing subpixel-interpolation in the DSP wait cycles of the data transfer loop to the host CPU.
http://os.inf.tu-dresden.de/~nf2/projects/projects.html

so No also made complete rendering engine on DSP...
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: 3D - F030 vs Amiga 1200

Post by dml »

calimero wrote: but how is it possible to achieve ST Ram speed when ST Ram bus is 16bit and 16MHz while DSP is 8 bit and 16MHz (?), right?
Well, DSP is 56bit and 32MHz :-) In fact there are 4 path widths in and around the DSP:

8bit (x 3 bytes) for the hostport (but interfaced at 32MHz)
24bit for most memory and some register ops
48bit for some memory and some register ops
56bit for some register ops

There is also the DMA path and I forget the width but its probably interfaced as 16<->24.
calimero wrote: that is cool but if DSP could render entire screen than you have another problem:
you can not fit entire frame (video) buffer to 96KB - 320x200x16bit is 128KB!
so you need to copy data from DSP Ram to ST Ram before VBL is over?!?
plus, you need to upload all new data for next frame?
You have to copy data anyway - the Videl can't display what's inside the DSP. So even if you fit the entire framebuffer on the DSP it still needs copied out at some point to STRam so the Videl (and you) can see it.

If you work this way (creating the framebuffer inside the DSP - btw this is not what I do generally but its good for some stuff) then it's best to do the display in slices which do fit inside the DSP and transfer each slice when rendered.

Uploading data is a separate thing from extracting display and both are optional. For a start you don't need to build a framebuffer inside the DSP, you can build simple commands and have the CPU follow them on the other side. This is how BadMood works.

As for uploading data - you only need to upload new data each frame if there isn't space to keep what you need between frames. So if you have less than 96k of code, tables, intermediate data then you don't need to upload anything at all. This is why BadMood doesn't use DSP texturing for all surface types - it would have to upload all the textures (including massive 256x128 things) even just to draw a 16x16 surface in the distance, and the cost isn't worth it.

So it makes sense to store small things between frames, and generate as much as possible - avoid transferring big things unless it's all going to be used.
dml wrote:... fit for that frame). The bottleneck and space problems need very careful management.
calimero wrote: interestingly, so DSP works almost as GPU/SIMD in modern day computers? :)
It can be 'twisted' to work like a GPU, for geometry and shading purposes, and/or for building the display from primitives. It can do a lot of other stuff though - whatever you want to cook up in DSP assembler. It's really meant to be a fast audio processor but it's programmable and fast so you can make it do very different things.
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2378
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: 3D - F030 vs Amiga 1200

Post by calimero »

dml wrote:
calimero wrote: but how is it possible to achieve ST Ram speed when ST Ram bus is 16bit and 16MHz while DSP is 8 bit and 16MHz (?), right?
Well, DSP is 56bit and 32MHz :-) In fact there are 4 path widths in and around the DSP:
sorry, I was talking about host port... not internally DSP :)
dml wrote:8bit (x 3 bytes) for the hostport (but interfaced at 32MHz)
...
There is also the DMA path and I forget the width but its probably interfaced as 16<->24.
hm... so host port have speed of 32MHz but it is wide only 8 bit? how do you read data from/to it? ...8bit by 8bit... or there is some kind of buffer where you can move entire word (16bit) or long (32bit), one at a time?

using DMA - can you load/store data without blocking 68030? directly from DSP to ST ram? does it have separate path or it block 030 bus?

and I have feeling that you do not use DMA :) why?
dml wrote:Uploading data is a separate thing from extracting display and both are optional. For a start you don't need to build a framebuffer inside the DSP, you can build simple commands and have the CPU follow them on the other side. This is how BadMood works.
"simple command" - so CPU will do actual drawing/rendering based on DSP data (pulling texture data from st ram and drawing to st ram)?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: 3D - F030 vs Amiga 1200

Post by dml »

calimero wrote: hm... so host port have speed of 32MHz but it is wide only 8 bit? how do you read data from/to it? ...8bit by 8bit... or there is some kind of buffer where you can move entire word (16bit) or long (32bit), one at a time?
It looks a bit like this:

[CPUREG:32]<-pipe[2]->[DSPREG:24]

So it' looks like a 32bit register on the CPU side - with the upper byte unused - and full 24bit on the DSP side. In fact the 32bit mapping on the CPU side is 3 separate byte ports but they can be accessed together as 32, 16 or 8bit by the CPU. Accessing the full 32bit address is often inefficient - when transferring blocks it makes more sense to do it in bursts of 16bit words.
calimero wrote: using DMA - can you load/store data without blocking 68030? directly from DSP to ST ram? does it have separate path or it block 030 bus?
DMA is a background transfer mechanism, it doesn't block the CPU although it does steal a very small % from the STRam bus 'budget' when active.

IIRC the CPU is the only processor which can configure and control the DMA, at least for STRam->DSP so the CPU needs to be involved at least as a DMA chain manager and to build/prepare the material for transfer.
calimero wrote: and I have feeling that you do not use DMA :) why?
It's usefulness depends on the application. The DMA is a simple mechanism - it just transfers stuff in a stream. You can't make decisions about the content of the stream once it has been built so you need to prepare it in advance of transmitting and that has other implications. It's good for tasks which suit it and if you design specifically for it.

If you can prepare stuff in advance and just send it in a block or a chain then DMA makes more sense than host port. If you need a tighter coupling between the processors then it's hard to use it effectively.

I can't use it easily in my project because there is a lot of feedback between drawing and what is allowed to be drawn next (occlusion) so you can't prepare too much in advance. There are other reasons but this is one reason I don't waste time trying to convert tons of code :)

calimero wrote: "simple command" - so CPU will do actual drawing/rendering based on DSP data (pulling texture data from st ram and drawing to st ram)?
Yes. The DSP does a lot of work to compress the command stream to the simplest representation, removing anything which would be wasted work (e.g. joining polygon spans together if they touch at the ends). These commands take very little time across the host port. The CPU then just works in a tight loop in one shader state, pulling data from STRam and drawing to the screen.

It's faster to have the CPU do less of this and do more on DSP (like store the textures there) but as I mentioned earlier this imposes hard limits very quickly - which is fine for some tasks but not others.
deeez
Atari nerd
Atari nerd
Posts: 44
Joined: Fri May 03, 2013 4:51 pm

3D - F030 vs Amiga 1200

Post by deeez »

calimero wrote:
dml wrote: Mikro has probably measured this. I've been working mainly in relative terms so I didn't check bandwidth and write down numbers. Pretty fast though - approaching (but not quite) the same as copying from STRam.
first, thanx for replay! :)

but how is it possible to achieve ST Ram speed when ST Ram bus is 16bit and 16MHz while DSP is 8 bit and 16MHz (?), right?

I seem to remember its something like 2.5MB/sec reading from DSP host port which is about half that of reading from ST-ram (copy ST-ram to ST-ram f that's what you meant dml)

Biggest gain from using DSP is being able to run things in parallel ie transform vertices on DSP while 030 is clearing the screen or rendering previously calculated triangles.

Fredrik.
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2378
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: 3D - F030 vs Amiga 1200

Post by calimero »

deeez wrote:
calimero wrote:
dml wrote: Mikro has probably measured this. I've been working mainly in relative terms so I didn't check bandwidth and write down numbers. Pretty fast though - approaching (but not quite) the same as copying from STRam.
first, thanx for replay! :)

but how is it possible to achieve ST Ram speed when ST Ram bus is 16bit and 16MHz while DSP is 8 bit and 16MHz (?), right?
DSP is 3x 8 bit - my guess is that one 24bit data is send in parallel - each cycle.
deeez wrote:Biggest gain from using DSP is being able to run things in parallel ie transform vertices on DSP while 030 is clearing the screen or rendering previously calculated triangles.
or, as Evil/DHS mention, if you have entire frame buffer in DSP - than you do not even need clearing/redrawing! :)

Fredrik.[/quote]
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: 3D - F030 vs Amiga 1200

Post by dml »

calimero wrote: DSP is 3x 8 bit - my guess is that one 24bit data is send in parallel - each cycle.
It's not very clear exactly how it couples because the accesses are split up into 8 bit pieces for the host bus and then recombined at each end, and there is a buffering mechanism in the middle with 2 levels.

So it's easier to talk in terms of MB/sec and forget the other stuff (somewhere between 2 and 3mb/s sounds about right). In any case, it's much faster than DMA in terms of raw transfer rate, which is about 0.8mb/sec.

DMA is mainly useful if the CPU is still very busy doing something else, and the DSP isn't wasting too much time in interrupt context catching DMA packets (IIRC the DMA mechanism is handled by interrupts at the DSP end, not DMA based so the DSP has to execute code to catch each packet and store it - however it's been 15-20 years since I looked at this so I may stand corrected!).
Biggest gain from using DSP is being able to run things in parallel ie transform vertices on DSP while 030 is clearing the screen or rendering previously calculated triangles.
This is true, at least in that mode of operation and when implemented well.

So long as the DSP is kept busy and isn't waiting on the CPU most of the time, it doesn't matter how much work the CPU does - that becomes free through parallelism.
or, as Evil/DHS mention, if you have entire frame buffer in DSP - than you do not even need clearing/redrawing! :)
This requires a very specific code architecture to use well, but it has a lot of potential.

I think the best way to use this is to spend 90% of the DSP ram on a partial framebuffer (say, N scanlines of a complete image) and reserve 10% for a small amount of code and temporary data.

You then construct a large DMA chain representing a complete displaylist for the image, which contains both code and data to be used with that code. You then stream the displaylist to the DSP and it executes the small code packets in series with the data. The image is built up inside the DSP.

If the image/framebuffer is large than the available memory, you have to stream the displaylist multiple times (effectively drawing the scene in chunks, at the cost of streaming the scene more than once).

This is a nice method although there is still a transfer rate issue (0.8mb/sec) for 'dense' data such as textures, which would need to be kept rather small otherwise most of the time is spent transferring those, and the DSP becomes idle waiting for them.

However if you can keep DSP and CPU mostly operating in parallel using host port alone then more work can be done per frame. This works best if the CPU is operating as a slave, texture sizes is on the large side, and the DSP is given a lot to do (complex shaders, spanbuffers, visibility, scene construction work)

The DMA route is probably better for light data e.g. lots of static geometry + smallish/reused textures, and with a sensible limit on the size of a DMA chain relative to the internal framebuffer size - because it takes a proportional amount of time to get the displaylist DMA'd no matter how fast the DSP is or how many cycles are free.
deeez
Atari nerd
Atari nerd
Posts: 44
Joined: Fri May 03, 2013 4:51 pm

3D - F030 vs Amiga 1200

Post by deeez »

The problem with having the frame buffer partly in DSP ram is clipping triangles. I haven't done this myself but I'm thinking the clipping has to be perfect otherwise you'll end up with tearing in the image. I guess you could add a postprocessing pass at the end to try and hide the artefacts but that will cost you extra time obviously.
It would be interesting to know if anyone has actually tried this solution?

Fredrik.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: 3D - F030 vs Amiga 1200

Post by dml »

deeez wrote:The problem with having the frame buffer partly in DSP ram is clipping triangles. I haven't done this myself but I'm thinking the clipping has to be perfect otherwise you'll end up with tearing in the image. I guess you could add a postprocessing pass at the end to try and hide the artefacts but that will cost you extra time obviously.
It would be interesting to know if anyone has actually tried this solution?

Fredrik.
Hi,

I haven't tried it on the Falcon's DSP but have used it in another case where stream processors were used to build offscreen surfaces.

Yes the clipping has to be done with care or you get problems as you say. It's a bit less trouble if the process is scanline based and you use framebuffer strips instead of rectangles. Better though to design with some flexibility (aim for rectangle capability) in case it needs to change for another reason.

When designing a rasterizer it's important to use fixedpoint for everything and keep any lost fractions from rounding in screenspace to correct texturing and clipping errors otherwise you get really bad joins and wobbles - it costs a little more but makes the above method easier to do well.

I think this should work on the DSP but the whole texturing thing is a bit problematic unless the texel:pixel ratio is kept close to 1:1 to limit wasted bandwidth (which really means mipmaps) and having the CPU figure out which mip to supply for each surface or group of surfaces is a real pain, and probably required to keep things going in one direction only (towards DSP, not asking for anything back from it).
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: 3D - F030 vs Amiga 1200

Post by dml »

deeez wrote:The problem with having the frame buffer partly in DSP ram is clipping triangles. I haven't done this myself but I'm thinking the clipping has to be perfect otherwise you'll end up with tearing in the image. I guess you could add a postprocessing pass at the end to try and hide the artefacts but that will cost you extra time obviously.
It would be interesting to know if anyone has actually tried this solution?

Fredrik.
Hi,

I haven't tried it on the Falcon's DSP but have used it in another case where stream processors were used to build offscreen surfaces.

Yes the clipping has to be done with care or you get problems as you say. It's a bit less trouble if the process is scanline based and you use framebuffer strips instead of rectangles. Better though to design with some flexibility (aim for rectangle capability) in case it needs to change for another reason.

When designing a rasterizer it's important to use fixedpoint for everything and keep any lost fractions from rounding in screenspace to correct texturing and clipping errors otherwise you get really bad joins and wobbles - it costs a little more but makes the above method easier to do well.

I think this should work on the DSP but the whole texturing thing is a bit problematic unless the texel:pixel ratio is kept close to 1:1 to limit wasted bandwidth (which really means mipmaps) and having the CPU figure out which mip to supply for each surface or group of surfaces is a real pain, and probably required to keep things going in one direction only (towards DSP, not asking for anything back from it).
User avatar
nativ
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4106
Joined: Mon Jul 30, 2007 10:26 am
Location: South West, UK

Re: 3D - F030 vs Amiga 1200

Post by nativ »

How about if you are calculating fractal based textures rather than using bitmaps? I would think recursive math in this form would be a winner?

Or do you still have to convert that back in to a graphical format to display?
Atari STFM 512 / STe 4MB / Mega ST+DSP / Falcon 4MB 16Mhz 68882 - DVD/CDRW/ZIP/DAT - FDI / Jaguar / Lynx 1&2 / 7800 / 2600 / XE 130+SD Card // Sega Dreamcast / Mega2+CD2 // Apple G4

http://soundcloud.com/nativ ~ http://soundcloud.com/nativ-1 ~ http://soundcloud.com/knot_music
http://soundcloud.com/push-sounds ~ http://soundcloud.com/push-records
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2378
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: 3D - F030 vs Amiga 1200

Post by calimero »

nativ wrote:How about if you are calculating fractal based textures rather than using bitmaps? I would think recursive math in this form would be a winner?

Or do you still have to convert that back in to a graphical format to display?
you need pixel data anyway in DSP ram.
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: 3D - F030 vs Amiga 1200

Post by dml »

nativ wrote:How about if you are calculating fractal based textures rather than using bitmaps? I would think recursive math in this form would be a winner?

Or do you still have to convert that back in to a graphical format to display?
If you're using generative techniques then you don't need to upload nearly as much stuff.

If the framebuffer is internal then you still need to extract it but you only have to do it once per frame, so limiting what you have to upload for each frame is a win.

Generative is fun and DSP is better at it than CPU, but it's an audio processor not a GPU so it's tough to do things that way quickly per pixel. If you're creative and keep some space for tables you can still do a lot of interesting stuff though.

The liquid shader in BM uses 20 instructions and only the builtin ROM table so it's very small. That approach combined with textures-as-tables can produce a lot of effects with very little data.

The most interesting thing about that approach is probably the fact that flexibility increases a lot with each operation added per pixel i.e. not proportionally. So if you're going to work this way, then might as well concentrate on good effects rather than 50Hz refresh :) the middle ground is a bit less interesting.
mikro
Hardware Guru
Hardware Guru
Posts: 2231
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: 3D - F030 vs Amiga 1200

Post by mikro »

calimero wrote:- I know that Mikro/Mystic Bytes made 3D engine on DSP where textures are also stored and calculated on DSP.
- does anybody elso done this?
Earx at least, from whom Mikro had taken the idea ;-)

There's no mystery how it works, instead of looking up into ST RAM you look up into DSP X/Y RAM. Then you just send the whole stuff to CPU using normal m68k instructions like:

move.w (a0),(a1)+ ; a0 points to DSP host port register

... and that's pretty much it. It's fast (fastest possible), you can even avoid synchronization with DSP. The biggest bottleneck is then clearing of screen buffer(s). Usually you clear screen while computing rotations and backface culling in DSP but it's not enough, clearing 320x200x16 takes more than it's acceptable for fluid viewer experience (far more than DSP needs). Then you can of course rewrite WHOLE screen from DSP but that wont help that much as CPU has nothing to do while waiting for DSP + then you must much more DSP reads (which are slower than CPU ones) which results in poor FPS again. Cheating, cheating, cheating, that's how we do things on Atari :)
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2378
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: 3D - F030 vs Amiga 1200

Post by calimero »

to refresh this thread with question regarding Falcons DSP :)

is it possible next scenario:

DSP create MC68030 opcodes (instructions) in his own memory and then using DMA transfer them to ST ram where MC68030 execute these instructions?

If DMA transfer is 0.8MB/s and it does not block 68030 or DSP than it can be used to deliver e.g. 26KB of data (including MC68030 instructions) per frame to ST ram.
...so DSP would "programming" MC68030 - something like CPU programming Cooper chip in Amigas :D
Last edited by calimero on Mon Jan 12, 2015 3:58 pm, edited 4 times in total.
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2378
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: 3D - F030 vs Amiga 1200

Post by calimero »

mikro wrote:There's no mystery how it works, instead of looking up into ST RAM you look up into DSP X/Y RAM. Then you just send the whole stuff to CPU using normal m68k instructions like:

move.w (a0),(a1)+ ; a0 points to DSP host port register

... and that's pretty much it. It's fast (fastest possible), you can even avoid synchronization with DSP.
so every read (move.w (a0),(a1)+) will automatically bring new (next) value to DSP host port?
does MC68030 need to check somehow if next value is prepared in host port register? (or need to wait between two move.w (a0),(a1)+ ?)
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
Post Reply

Return to “Demos”