a golden age of Amiga

[Karlos]

How about getting AROS working properly on the Raspberry Pi and working on an integrated 68K JIT for ARM?

[Karlos]

ARM is the future of computing though, I'm sure of that.  x86 has to end sooner or later, it's too stupid to continue indefinitely.  Surprised it's lasted this long to be honest.

ARM is very much the present of computing, let alone the future. I wouldn't write off the x86 though. The current generation of these processors is a far cry from the clunky old components. The modern 64-bit implementations are actually quite nice and extremely high performance.

[Karlos]

Oh yeah there's a really neat RISC core hiding behind all that microcode gubbins, shame we can't get at it directly and turn off all those redundant transistors...

Still.  Check this out: http://www.youtube.com/watch?v=oLte5f34ya8

this is the sort of trick a new Amiga ought to aim for.  Forget GPUs, massive parallelism is the way to go.  Maybe a single standard supervisor CPU with a whole load of barrel co-processors similar to the UltraSparc T1.  The throughput of those things is incredible, given the right workloads.  They threw away such complexities as out-of-order execution in exchange for simultaneous multithreading, thus all but eliminating cache latencies.  This strategy would be perfect for highly paralellisable workloads such as ray-tracing.

We could call them Juggler Chips!

On the contrary, I'd say forget CPUs and focus on GPU if you like massive parallelism. My (now old news) quad core can run four threads concurrently. My (equally old) GTX275 can run 30720 of them at full pelt. Thread switching to hide latencies caused by memory access and the like is completely built into the hardware.

Full ray tracing is a tough one due to the tendency of threads to become divergent in their flow of execution but far from impossible with modest GPUs today. Then there is ray marching, which is the poor man's next best thing. And they can do that entirely realtime. In your browser, even, if you happen to have a WebGL capable one and supported hardware.

[Karlos]

On ray marching, or "volume ray casting" as they call it, Wikipedia states

"However, adaptive ray-casting upon the projection plane and adaptive  sampling along each individual ray do not map well to the SIMD  architecture of modern GPU; therefore, it is a common perception that  this technique is very slow and not suitable for interactive rendering.  Multi-core CPUs, however, are a perfect fit for this technique and may  benefit marvelously from an adaptive ray-casting strategy, making it  suitable for interactive ultra-high quality volumetric rendering."

http://en.wikipedia.org/wiki/Volume_ray_casting

Here Intel are doing real time ray tracing show off their Nehalem core:
http://www.youtube.com/watch?v=ianMNs12ITc

Obviously that is an expensive top-of-the-range CPU there (or rather, four of them).  It makes me wonder what could be done with a big bunch of ARM chips.  GPUs can be made to do this but you'd not be using them optimally.  Likewise even a general purpose chip like the Nehalem is a lot more complex than necessary.

I think to sum it up, GPUs are designed for a task too specific, while mainstream CPUs are designed for tasks too general.  I wonder if this goes some way to explain AMD's strategy with their Bulldozer chips, which seems to have confused a lot of people.

Wikipedia must be out of date there. I can assure you raymarching works fine on my gtx 275 and better still on fermi based GPUs which have superior divergent conditional branch handling and cache. There are several realtime examples written entirely in glsl for Mr doob's web glsl playground which run at full speed on my kit. I've tested even better CUDA specific examples. Lastly, even SIMD does not accurately describe the operation of these GPUs. SIMD better describes SSE or altivec. Its a poor description for modern stream processors.

[Karlos]

Shader engine is an obsolete term. Modern GPUs are massively parallel stream processors that are Turing complete. You can use them to perform any inherently parallel task you like, provided you know how to code it. If you program them to ray trace, that is exactly what they do. Or you could program them to perform all-pairs n-body particle interaction, or brute force md5 sums. They are nothing whatsoever like fixed function, discrete shade unit graphics chips of a few years ago any more than a modern multicore x64 is like a 286. Their main application is graphics processing because that is the sort of inherently parallel task they excel at, whether it is simple rasterization or complex per pixel shading. However, you need to look at this in the abstract. It can be any algorithm operating on a set of data using thread per unit data parallelism. There is no shader, the shader is merely a software construct running on a truly general purpose (algorithmically speaking- stream processor. And it crushes CPUs for this

[Karlos]

The modern GPU is basically a very large collection of arithmetic/logic units. 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. Now imagine a set of work supervisors that oversee them, detecting when clusters are waiting for IO and able to switch the thread group they are executing for one that is ready to go. Finally, imagine these being served by multiple memory controllers on demand. That's your basic GPU today. Current GPUs can even execute multiple kernels concurrently, so if one cannot occupy all the stream units, you can run more.

[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]

[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.

[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]

[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

[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 :-/

[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.