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?"

Comments

need a reason

[b1ufox]

Need a reason for extra cores inside your box? No :)

How many do I need

[Moraelin]

Lemme see, at this rate I'll need: 9 cores for the raytracer, 7 cores for the physics simulation, 5 for the AI, 3 for the OS, and of course

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

Re:How many do I need

[Freaky Spook]

One core to rule them all

One core to find them

One core to bring them all

And in the darkness bind them

You just installed Vista onto that rig didn't you

*Ducks*

Gaming

[Anonymous Coward]

There are already ray traced games. :O

http://graphics.cs.uni-sb.de/~morfiel/oasen/

Re:Gaming

[Vario]

They managed to get reasonable frame rates with a FPGA board, which is rather slow compared to modern GPUs. A lot of special effects like diffraction are included and don't kill the framerate. This might be a very interesting alternative to more texels/s and shaders.
It just looks good as well: http://graphics.cs.uni-sb.de/~woop/rpu/rpu.html

Put it on the GPU

[TheRaven64]

The thing about ray tracing is that it's the archetypal embarrassingly parallel problem that makes heavy use of floating point arithmetic. The thing about GPUs is that they are incredibly parallel processors optimised for for floating point operations.

Take a look at the proceedings from any graphics conference in the last three or four years, and you will see several papers which involve ray-tracing on a GPU. Actually, not so many recently, because it's been done to death. The most impressive one I saw was at Eurographics in 2004 running non-linear ray tracing. As the rays advanced, their direction was adjusted based on the gravity of objects in the scene. The demo (rendered in realtime) showed a black hole moving in front of a stellar scene and all of the light effects this caused.

Won't happen soon.

[midkay]

It's extremely unlikely that anything will go anywhere with raytracing in the near future. Raytracing takes a tremendous amount of power - apps that demonstrate it in realtime usually run quite choppy, and they're very minimalistic to boot; ugly textures, very simple geometry, very confined areas...

The main benefits of raytracing in games would be:
1) Shadows; they'd be Doom 3-like. Several games have full stencil shadows and that's just how raytraced ones would look: sharp and straight. The difference? Raytraced ones would take a ton more power and time to compute.
2) True reflection and refraction. We can "fake" this well enough - for example, see the Source engine's water, incorporating realtime fresnel reflections and refractions. Though Source's water's "fake" refraction/reflection aren't pixel-perfect, and are only distorted by a bump-map, it certainly looks great.

Honestly, considering the small gain in visual quality (although a major gain in accuracy) - it's like going after a fly with a bazooka. Sure, once we get to the point where there's enough processing power to deal with this well enough in realtime, it will happen - but don't expect it soon, and don't expect that huge a difference. Nicer reflections and refractions (which already look good today) and pixel-perfect shadows (looking just the same as stencil shadows in some newer games).

Raytracing vs. Scanline for Realtime

[greazer]

I've seen the topic of realtime ray-tracing and hardware accelerated ray-tracing come up countless times over the past 15 years. In the 80's and 90's, a realtime ray-tracing acceleration chip was always around the corner. Some products did actually emerge, but never quite caught on. The reason for this is not because "commercial graphics industry has been intent on pushing raster-based graphics as far as they could go". Quite the contrary; it's much more elegant algorithmically (and hence 'easier') to implement a ray-tracer than a scanline based renderer. However, there's a fundamental limitation of ray-tracing that make it unappealing performance-wise. Cache coherence for ray-tracers suck.

All rendering algorithms boil down to a sorting problem, where all the geometry in the scene is sorted in the Z dimension per pixel or sample. Fundamentally, scanline algorithms and ray-tracing algorithms are the same. For primary rays, here's some simpliefied pseudocode:

      foreach pixel in image
        trace ray through pixel
        shade frontmost geometry

The trace essentially sorts all the geometrty along its path.

A scanline algorithm looks like this:

      foreach geometry object in the scene
        foreach pixel geometry is in
          if geometry is in front of whatever is in the pixel already
            shade fragement of geometry in pixel
            replace pixel with new shaded fragment

As you can see, the only distinction is the order of the two loops. For ray-tracing, traversing the pixels is in the outer loop, and the geometry in the inner loop. For scanline rendering, it's the opposite. This has huge consequences in terms of cache coherency. With scanline methods, since the same object is being shaded in the inner loop, and neighboring fragments of the same object are being shaded, cache coherency tends to be extermely high. The same shader program is used, and likelyhood of the texture being accessed from cache is very good. The same can't be said for ray-tracing. You can shoot two almost identical rays but touch wildly different parts of the scene. Cache coherency relative to scanline rendering is abysmal.

This one performance side-effect of ray-tracing is the only reason we haven't seen any serious ray-tracing for realtime applications. Even in offline rendering, scanline rendering dominates even though software ray-tracing has been available from the beginning of CG. For ray-tracing to become viable, we need more than just more CPU cores. We need buses fast enough to feed all the cores in situations where we have an extremely high ratio of cache misses. Unfortunately, the speed gap between memory speeds and compute power seems to be increasing in recent years.