Add Another Core for Faster Graphics

Dzonatas writes "Need a reason for extra cores inside your box? How about faster graphics. Unlike traditional faster GPUs, raytraced graphics scale with extra cores. Brett Thomas writes in his article Parallel Worlds on Bit-Tech, 'But rather than working on that advancement, most of the commercial graphics industry has been intent on pushing raster-based graphics as far as they could go. Research has been slow in raytracing, whereas raster graphic research has continued to be milked for every approximate drop it closely resembles being worth. Of course, it is to be expected that current technology be pushed, and it was a bit of a pipe dream to think that the whole industry should redesign itself over raytracing.' A report by Intel about Ray Tracing shows that a single P4 3.2Ghz is capable of 100 million raysegs, which gives a comfortable 30fps. Intel further states 450 million raysegs is when it gets 'interesting.' Also, quad cores are dated to be available around the turn of the year. Would octacores bring us dual screen or separate right/left real-time raytraced 3D?"

Not quite

[Aceticon]

If i remember it correctly from my days of playing with POVRay [povray.org] (free raytracing app), the time it took to raytrace an image depended on things like the presence (or not) of semi-transparent, semi-reflective surfaces and on the number of light sources.

If this is still the case, then going from the current rendering techniques in games to raytracing would result in images with more realistic reflections and lighting but, due to performance tradeoffs, few reflective surfaces and light sources.

Besides, at the moment what games need the most is beter AIs and procedurally generated content, not yet another layer of eyecandy that requires gamers to upgrade their hardware (again).

Re:That should read 450 million raysegs

[quenda]

+4 informative!? Where's the "-1 bleedin' obvious" mod? Are there not enough serious errors in the summaries to worry about?

Re:How many do I need

[Ihlosi]

One core to rule them all
One core to find them
One core to bring them all
And in the darkness bind them ;)

You must be talking about the one core that's part of the TPM.

"entirely vectors"

[Joce640k]

Raytracing is pretty much entirely vectors isn't it?

No, ray tracing is all about searching databases for ray-object intersections. That's what GPUs can't do at all.

Re:Won't happen soon.

[Anonymous Coward]

the way I see it, sharp shadows are not very realistic, unless you have a point light. before going to raytracing, we should get area shadows, that are cast from an area light (allmost all light sources have area/volume). we should also get shaders that mimic the subsurface scattering, i.e. indirect illumination that is generated from the light bouncing off objects.

not that i care, since i dont play them stupid video games.

Film at 11

[jalefkowit]

A report by Intel about Ray Tracing shows that a single P4 3.2Ghz is capable of 100 million raysegs, which gives a comfortable 30fps.

Extra, extra! This just in! Report from CPU vendor discovers that you should spend more money on your CPU and less on your graphics card!

Shocking, I tells ya. Shocking.

let's do the math...

[Anonymous Coward]

Four 3.2 GHz CPUs gives:

3.2 * 1,000,000,000 * 4 = 12,800,000,000 Hz

Assume resolution 640x480 and framerate 30:

640 * 480 * 30 = 9,216,000

OK, now let's see how many cpu cycles we're gonna have for each ray:

12,800,000,000 / 9,216,000 = ~1388.89

Conclusion:

Can you complete a raycast in one and a half kHz? Not a chance.

And even if you could - there would be _nil_ cycles left for sound, game mechanics etc etc... //0xFE

Re:Put it on the GPU

[smallfries]

Erm, yes it is actually. You and the other replies that pointed out that it scales better with complexity are correct. Google confirms that my memory was a bit off on this one...

Re:Put it on the GPU

[smallfries]

When I read it the way that you've put it, it does sound plausible. But the Intel quote was a bit ambiguous - you could read it as 100m rays per image, which I still think is a more natural way of describing it. If you read it the other way as 100m rays per second then it would be a division there, making it about 350 cycles per ray. The actual math could be done that quickly, but it would be very dependent on how cache friendly the data is. Using 3m rays per frame is roughly 3 rays per pixel - beneath the threshold for removing aliasing. Conventional wisdom is about 16 rays per pixel to get nice antialiasing. This of course assumes that those 350 cycles are including subsequent bounces for each ray - not treating each bounce as a separate ray. With a memory latency of ~150 cycles this means that the computation of each ray needs to pipeline exceedingly well...

Re:Put it on the GPU

[lenhap]

The problem is not raytracing, but geometric complexity. Raytracing does not scale nicely with the amount of geometry - mainly because of the shadow rays that have to be scattered from each intersection.

Did you even read the article? I understand this is slashdot where no one RTFA but come on...

The whole benefit of raytracing, according to the article, is that it scales logarithmically with complexity (number of triangles) and shadows are free (shadows are just a side effect of raytracing, not something extra like with raster graphics). So in other words, concerning raytracing, you have to increase the complexity of a viewable scene (viewable meaning: if an object is hidden by another object, it doesn't add to the complexity) by 10 to double the computation needed vs. raster graphics which scale linearly with complexity in a scene (even non-viewable graphics add to the complexity) meaning a doubling of the complexity doubles the computation needed.

I love the spreading of FUD and FUD* in slashdot as much as the next guy, but come on...
*in this case I mean FUD as F'd Up Drivel.