Quote:Original post by Spoonbender
But maybe you have a raytracer that can do it? If you can manage to make realtime raytracing viable on a normal computer, I suggest you call NVidia or ATI to hear how many millions they're willing to pay for your algorithms. It won't be a single-digit number, I can guarantee that. :)

I think that this one shows that it's not so far into the future as you may think:
RealStrom Benchmark

Average around 20 fps (probably more) in 512x384 on my AMD 3500+
And with a new AMD Dual Core CPU like X2 4800+ this would probably go very fast in 640x480

Quote:Original post by Spoonbender

Quote: dont know where you got the exponentially, since it wrong, but now consider the case where these 'adaptiotions' include the CPU becoming massively parralel... there goes the GPU's main advantage.

Not really, no. CPU's are just going for multicores in the future. A GPU tends to rely more on something like instruction-ievel parallelism. You write one stream of instructions, and the hardware (or the driver) splits it up between the pipelines, or different cards in the case of SLI.

With a CPU, you're going to have to rely on thread-level parallelism, meaning you have to create and run those 16 identical threads yourself, just to emulate a modern 16-pipeline graphics card, except you'd have to worry about making these threads interact properly, without deadlocking the entire program, or stalling each others.

The GPU still has a massive advantage there.

im not talking about todays x86's, which are indeed clearly not designed with any form of parralelism in mind.

Quote:Original post by ApochPiQ

With the special-purpose dedicated processing power of modern GPUs, it is extremely unlikely that even a master graphics wizard would be able to write a software renderer that could hold its own against hardware-accelerated rendering in the general case.

That's on x86 . Other architectures do not necessary have to perform that bad. Really, you noticed that programmability of graphics cards grows. But as programmability grows, it becomes more and more close to general purprose computation device. As programmability increases, "dedicateness" decreases.

More programmability just means that so-called "hardware rendering" are more and more "software rendering", in fact. Really, CPU where software renderer works is hardware too; and we call it "software rendering" just because you write program that is executed on CPU and do rendering.

x86 CPU versus GPU is closer and closer to good-old "mainframe versus supercomputer" thing (mainframe would suck at rendering, or at playing chess, general purprose supercomputer would suck at running, say, 1000 instances of something dumb like database or text editor, but would be good at rendering, video processing, or something similar - it is highly parallel). Except that GPU is sort of stripped version of general purprose supercomputer, lacking anything that is not needed for graphics.

In summary, the more things are programmable, the closer it is to software renderer. You write shader program - actually you write small piece of software renderer. You write raytracer as shader program - it's essentially software renderer.

[Edited by - Dmytry on June 11, 2005 11:30:34 AM]

Quote:
And those that say raytracing isnt fast enough (yet) for games isnt thinking outside the box

Oh? Show me one single application that's able to run raytracing realtime.

You apparently didnt read what I wrote, instead you clipped a single sentence and used it out of context. Perhaps you stopped reading at that statement.

"oooh! I can contradict that sentence!"

Try reading paragraphs first.