a golden age of Amiga

[Mrs Beanbag]

I guess I misread what you meant. Perhaps it would be best to outline in more detail what design you had in mind for the 'juggler chip', I'm interested to hear your thoughts.

Ok just look up UltraSPARC T1 to get what I mean.  I'll summarise.  Traditionally CPUs have been designed for single-threaded performace, by inventing such things as instruction-level parallelism (you can do several consecutive instructions at once if they don't clash), branch predication, speculative execution, out-of-order execution etc.. All of these things require extra circuitry of course but it's worth it for the performance boost.  Problem is you don't get 2x performance for 2x transistors so then multiple cores came into play.  But lots of programs don't run in multiple threads so they still try to maximise the performance of single cores.  And they are still held back when one instruction has a dependency on a previous one that hasn't finished yet, or it's waiting for memory reads etc..

UltraSPARC T1 took a more holistic approach.  Knowing servers always run umpteen threads at once, there's really no point in all that extra complexity to get the most single threaded performance.  So they ditched it all and instead made a CPU core that could switch threads on every cycle.  They only have to have a register file for each thread and rotate them round (hence the term "barrel processor"), and you can get rid of a whole load of complexity and go back to a very simple core that only does one instruction at once, which gives you room for loads more cores on a die, and cache misses can be made to vanish into the background.  Single-thread performance is terrible, but if you can throw enough threads at it it can keep up with CPUs that run at far faster clock speeds.  The T1 typically ran at 1.2GHz and, given the right sort of workloads, could keep pace with 3GHz Xeons.

[Mrs Beanbag]

Well that makes sense but

Think of these as very simple CPU cores where stuff like conditional branching is expensive but data processing is not. Then imagine them in clusters, each cluster running the same code but on different data. Not like a SIMD unit, but as an array of cores, able to branch independently but optimal when in step.

see this is where I'm getting stuck, surely independent conditional branching is exactly what ray tracing needs a lot of.

Also the kernel doesn't have random access into a large area of memory (where your scene might be stored, for instance) but only to the small portion that comes in on the stream, yes?

[Karlos]

Well that makes sense but

see this is where I'm getting stuck, surely independent conditional branching is exactly what ray tracing needs a lot of.

Precisely, which is why I said it's not an ideal algorithm. However, the handicap for it is becoming less and less with successive iterations of GPU architecture. The Fermi, for example, introduces more CPU like features, including cache memory. Which helps the next thing you mention...

Also the kernel doesn't have random access into a large area of memory (where your scene might be stored, for instance) but only to the small portion that comes in on the stream, yes?

Yes and no. You can do random access on current cards. Like conditional branching, it's not ideal. But far from insurmountable. nVidia demonstrated realtime raytracing using CUDA a couple of years ago. Of course, GPUs open up a possibility of hybrid rendering techniques. They can perform the entire primary ray calculation as a regular rasterization pass and focus only on tracing secondary rays.

Example:
[youtube]kcP1NzB49zU[/youtube]

[HenryCase]

UltraSPARC T1 took a more holistic approach.  Knowing servers always run umpteen threads at once, there's really no point in all that extra complexity to get the most single threaded performance.  So they ditched it all and instead made a CPU core that could switch threads on every cycle.  They only have to have a register file for each thread and rotate them round (hence the term "barrel processor"), and you can get rid of a whole load of complexity and go back to a very simple core that only does one instruction at once, which gives you room for loads more cores on a die, and cache misses can be made to vanish into the background.  Single-thread performance is terrible, but if you can throw enough threads at it it can keep up with CPUs that run at far faster clock speeds.  The T1 typically ran at 1.2GHz and, given the right sort of workloads, could keep pace with 3GHz Xeons.

I see, thank you for the information. That design makes sense for server chips, where you have a high number of unrelated threads, but expanding this type of architecture to be more generally useful does require looking at memory management. The main issue with parallel computing is managing memory, having the processing power to deal with multiple threads is easy in comparison.

Of course, it depends on what you're looking for. If you just want a ray trace accelerator then these issues are not so pressing. If you'd like to explore the memory issues more (and solutions to them), I can highly recommend this video on concurrency in Clojure, which offers the best solution I've found to date on making programming parallel systems (comparitively) easy to manage:
http://blip.tv/clojure/clojure-concurrency-819147

Also the kernel doesn't have random access into a large area of memory

How much memory do you anticipate being adequate? Graphics card memory is fairly large these days, can get cards with 1GB directly on the graphics card, for example. Plus, the PCI-E bus these cards are plugged into isn't exactly sluggish.

[Karlos]

How much memory do you anticipate being adequate? Graphics card memory is fairly large these days, can get cards with 1GB directly on the graphics card, for example. Plus, the PCI-E bus these cards are plugged into isn't exactly sluggish.

You can pick up a single GPU GTX580 card with 3GB right now if you have a fat enough wallet.

[Mrs Beanbag]

Of course, it depends on what you're looking for. If you just want a ray trace accelerator then these issues are not so pressing.

The model I have in mind is one where your operating system will run on a fairly standard dual or quad core CPU, but bulk calculations can be done on a set of co-processors with the barrel-architecture mentioned above.

[/QUOTE]How much memory do you anticipate being adequate? Graphics card memory is fairly large these days, can get cards with 1GB directly on the graphics card, for example. Plus, the PCI-E bus these cards are plugged into isn't exactly sluggish.[/QUOTE]

It's not the total amount of memory that's the problem, it's the random access.  The entire point of "streaming processor" is that the data comes in sequentially (more-or-less).  For ray-tracing you need to traverse the scene as a tree structure independently for each pixel, so it's difficult to serialise into a stream, because it's recursive rather than linear.  But the tree itself is static, so it can be in a read only memory.  The complication is that this read-only memory has to be accessed by all the threads simultaneously, but because it's guaranteed not to change during rendering there aren't any cache coherency issues there.  Each thread can have its own local data area and output buffer, and there are no interdependency issues.  The outputs can be combined after all threads complete.

I'm thinking of a cyclic arrangement something like this:

[CPU] --> [input data] --> [barrel coprocessors] --> [output buffers] --> [CPU]

which is kind of like a semi-streaming set up, I guess.  The output can still be streamed even if the input cannot.

There could be some kind of "burst unit" that transfers the output back to the input for the next iteration, which would be useful for physics simulations.

[Mrs Beanbag]

Example: (youtube)kcP1NzB49zU

I did see that, it's neat, but it seems to be doing some crude form of render while you're moving it about and only does real ray tracing when you leave it still, and takes a short while to do it.  The Intel Xeon demonstrations were full ray tracing in real time.  Granted a Xeon setup like that would set you back a few grand...

[Karlos]

I did see that, it's neat, but it seems to be doing some crude form of render while you're moving it about and only does real ray tracing when you leave it still, and takes a short while to do it.  The Intel Xeon demonstrations were full ray tracing in real time.  Granted a Xeon setup like that would set you back a few grand...

Even the crude render is ray traced, it's just not iterated as far. I'm a GPU fan for a number of reasons.They are massively powerful, cheap (comparatively) and to me, represent the logical evolution of what the Amiga's custom chips could have been. You do anything from knocking up old Amiga style raster bars to realtime physics simulation, all running entirely on the GPU.

Incidentally, if you want to see what you can do on a slightly more serious (remember, the garage demo was running on a gaming card) GPU in realtime, check what the quadro 6000 can do:
[youtube]QaKwLp77kjQ[/youtube]

[Mrs Beanbag]

Even the crude render is ray traced, it's just not iterated as far. I'm a GPU fan for a number of reasons.They are massively powerful, cheap (comparatively) and to me, represent the logical evolution of what the Amiga's custom chips could have been.

No argument, I've always been a fan of offloading things to separate units so the CPU could twiddle its thumbs, just not convinced that streaming processors are the ultimate solution.  Maybe there is some way to efficiently "stream" recursively...

You know, the Amiga's old blitter was this >< close to being able to do texture mapping.  If only you could use the B source DMA in line drawing mode...

Incidentally, if you want to see what you can do on a slightly more serious (remember, the garage demo was running on a gaming card) GPU in realtime, check what the quadro 6000 can do:
(youtube)QaKwLp77kjQ

Nice, anyone got £4k to spare?

[Karlos]

No argument, I've always been a fan of offloading things to separate units so the CPU could twiddle its thumbs, just not convinced that streaming processors are the ultimate solution.  Maybe there is some way to efficiently "stream" recursively...

The demands are getting greater all the time and they're achieving it. nVidia have a stake in HPC. Half of the features added in the GF100/110 chips were more to do with general computing than traditional rasterized 3D graphics. The latter generally doesn't need full IEEE754-2008 conformance, EEC, caching etc.

You know, the Amiga's old blitter was this >< close to being able to do texture mapping.  If only you could use the B source DMA in line drawing mode...

Did you see the thread recently where someone (sorry, I forgot the username) got sub-pixel correct line drawing and (slightly buggy) sub-pixel correct polygon rendering out of ECS? Damned impressive stuff.

Nice, anyone got £4k to spare?

Still cheaper than a bucketful of high end Xeons

[actung_bab]

Dear Friends:

I believe if we all work hard dedicated, we can bring about a new
golden age of amiga.
Let's do it !!!

Rednova

Well almost seems that way doesint it i have to agree alot to be thankfull for
I think if you got new hardware your got the Second golden age Maybe when
PPC cards and then A! one hardware so Know, we got 3rd Golden age
Depending how you look at things i guess but for me its great even if i havent got,
The hardware in front of me i got the oppunity to buy it if i wish to make it my first priorty
As my first hobby which it isint for last 6 years its been hifi gear dvds and know motorcycles A 1992 VFR 750 honda (rc36)

For me i run the bbs athough getting no callers at present hehe
But that makes the old 1200 enjoyable to turn on and love fiddling with it

Given i get the  time with family commitments

But we got remember alot people work on amiga software where always
gifted people did it for the love of it not getting pid a fortune (sharware)

These days seems its mostley about making money ie iphone apps etc

I think catch 22 thing , and not the devolpers fault or anyones
WE got the hardware but need to have people buying more software
To encourage growth in the market but its never going be like in the 80s
The world moved on and its not sad its just life
Those days everthing was new and excitng today little that brand new just reinventing the wheel .
So No not in the way you hoped for but am not going rain on your parade

Dude if you wish for that and its in your heart go for it buddy

keep posting no harm in talking about ideas can catch on and what made steve jobs person he was
Even was bit of a Hard man to his people though

Ps when laptop gets on the market i will be buying that as it be afforadable for me even with amiga
At number 3 On priority list

[Mrs Beanbag]

Did you see the thread recently where someone (sorry, I forgot the username) got sub-pixel correct line drawing and (slightly buggy) sub-pixel correct polygon rendering out of ECS? Damned impressive stuff.

I did not...

Still cheaper than a bucketful of high end Xeons

Heh maybe, but Xeons are over-spec anyway, as I've been saying, we don't need all that superscalar jazz if we can throw enough threads at the problem.

But this is even better...
grmanet.sogang.ac.kr/seminar/RPU.pdf

[Karlos]

I did not...

Found it:

http://www.amiga.org/forums/showthread.php?t=60315

-edit-

Heh maybe, but Xeons are over-spec anyway, as I've been saying, we don't need all that superscalar jazz if we can throw enough threads at the problem.

Actually, you've just brought the conversation full circle. The reason I brought up GPU in the first place was this.

For multiple CPU approaches to massive threading, though there are other complications. Amdahl's law, for one :-/

[HenryCase]

Did you see the thread recently where someone (sorry, I forgot the username) got sub-pixel correct line drawing and (slightly buggy) sub-pixel correct polygon rendering out of ECS? Damned impressive stuff.

Karlos, is this thread referring to the same demonstration?
http://www.natami.net/knowledge.php?b=6¬e=43776

EDIT: Ah, I see you found what you were looking for.

[Karlos]

Karlos, is this thread referring to the same demonstration?
http://www.natami.net/knowledge.php?b=6¬e=43776

EDIT: Ah, I see you found what you were looking for.

Yep, that's the one. I read his entire set of blog articles on the subject in the end. It was quite informative. So much cool stuff was locked away in some of that old hardware, never to be really exploited by anybody. More's the pity.

[Mrs Beanbag]

Actually, you've just brought the conversation full circle. The reason I brought up GPU in the first place was this.

In that case, it was full circle as soon as I started!  This is exactly why I brought up UltraSPARC T1, a CPU designed specially for large numbers of threads with no regard for single-thread performance.

But, I hasten to point out, I'm considering this for a co-processor, not the main processor.  I'm still thinking about how the memory system would work.  I reckon there must be some way for a streaming unit to send the root of a tree to each core, and then the core can choose its path down the tree, so you can get the best of both worlds.  Considering the FPGA article above, efficient real-time ray tracing is still a long way from current GPUs and CPUs.  Both can do it, but both have to sweat.