Add Another Core for Faster Graphics 237
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?"
need a reason (Score:5, Funny)
Gaming (Score:5, Interesting)
http://graphics.cs.uni-sb.de/~morfiel/oasen/ [uni-sb.de]
Re:Gaming (Score:5, Informative)
It just looks good as well: http://graphics.cs.uni-sb.de/~woop/rpu/rpu.html [uni-sb.de]
Note that OpenRT is not open source (Score:3, Interesting)
Oasen is based on "OpenRT [openrt.de]" --- which is entirely proprietary, and is NOT open source. Their FAQ explains that clearly.
I'm sure that I'm not the only person annoyed at their use of "open" to mean "closed".
Time to look for an open-source raytracing engine designed for interative use
Another one (Score:2, Troll)
Re: (Score:3, Interesting)
I remember a talk from someone (John Carmack I think) saying something like raytracing is nice but overkill. Today's hardware maybe be able to handle realtime raytracers but no way near the quality you can get from current 3D engines.
Most special effects you see in current engines are approximation/hacks compared to what you can do with a raytracer but it's also way cheaper to compute.
It's the same kind of relationship than between texture maps vs procedural textures. Procedural textures are better for a
Scientific American (Score:4, Informative)
It's been done... (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2, Informative)
That should read 450 million raysegs (Score:3, Informative)
450 million raysegs not 450 raysegs.
Re: (Score:2)
Re: (Score:3, Funny)
Put it on the GPU (Score:5, Interesting)
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.
It's not JUST FP that's the issue (Score:5, Interesting)
It's not just the sheer number of FP calculations that can be the problem. Once you get away from the first (or perhaps even second) level of rays, you end up losing coherence between neighbouring rays which causes memory page/cache thrashing. This is not a nice thing on a GPU.
Re:Put it on the GPU (Score:5, Interesting)
But the GPU is interesting for raytracing. As it moves closer towards a giant floating point vector machine the motivating application will become raytracing. So at the moment a 7800gtx can push 280Gflops. That is 2800 cycles per ray for a single frame. (BTW Intels figures in the article are bullshit. 100mil rays at 30fps = 3 billion rays per second. Roughly one ray per cycle on averge. They are counting a huge number of rays that have been optimised out of the scene, eg shadows or interpolated from pervious frames using a cache).
The raw horsepower is getting there on the card but at the moment the communication soaks up all of the time. Raytracing is the poster-child problem for parallelisation - assuming that you have random access (readable) global memory. If you need to partition the memory into the compute nodes it begins to get harder. In a GPU building datastructures to hold the information is the bottleneck, and it drops the speed by factors of 100s or 1000s. Nvidia and ATi have given the general-purpose community hints that they will improve performance in reading data-structures so this particular roadblock may disappear. A real scatter operation in the fragment shader would be nice, but you would have to gut the ROPs in order to do it. This may happen anyway as the local-area operations that the ROPs compute could fold into fragment operations. To increase the write bandwidth in the card the retirement logic needs to start retiring 'pages' of pixels anyway, over a much wider bus. Otherwise the number of feasible passes per pixel will always be capped by the speed that the ROPs can retire the data.
So given how hard it would be to *efficiently* raytrace on a GPU - why bother when you can throw so much more raw horsepower at faking it with cheap raster techniques?
Re: (Score:3, Informative)
Erm, that's just flat wrong. With the correct bounding volume hierarchy, ray tracing scales with geometric scene complexity much better than scanline methods. It is one of the reasons that offline raytracing renderers can handle such huge datasets efficiently. Also, the number of shadow rays used is *completely* independent of the "amount of geometry" in a scene.
Re: (Score:3, Insightful)
Re:Put it on the GPU (Score:4, Funny)
Yes but myopia would seem to be one of those problems that ray tracing would be much better at solving since it can handle refraction directly.
Re: (Score:2)
Ahh....this to me says you screwed up the math. 100m rays at 30f/s = 3.333333m rays per frame not 3b r/s. You multiplied when you should have divided. In other words, it looks like Intel got it right and your math is in the south pasture.
I still agree with the mods...your post is interesting.
Re: (Score:3, Insightful)
Scientific American article (Score:2)
-1, Wrong (Score:3, Interesting)
Re: (Score:3, Insightful)
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 somet
Umm no (Score:2)
It actually scales exceptionally well with the amount of geometry O(log n) where GPUs suck. Read the linked article. Also, the spatial index used in ray tracing is a non-trivial data structure which is not handled well on a GPU. I've also found that ray tracing works better (fewer/no artifacts) with double precision floating point which is not available on a GPU. In a few years, the CPU will be quite capable of realtime ray tracing, so at that po
Re: (Score:2)
The main advantages of ray tracing is physically correct lighting, shadows, and reflections, as well as the ability to use any geometric shape that can be mathematically defined (e.g. a
Why on the CPU? (Score:2, Funny)
NB: The only raytracer I've ever written was in PHP and it managed about 0.01 frames per second with very basic geometry and no textures, so I'm probably very, very wrong.
"entirely vectors" (Score:5, Insightful)
No, ray tracing is all about searching databases for ray-object intersections. That's what GPUs can't do at all.
Re:"entirely vectors" (Score:4, Interesting)
Re: (Score:2)
Is ray-tracing "tied in with" vector graphics?
Re: (Score:3, Funny)
So the choice for php+sql might not be such a bad idea after all ;)
Not quite (Score:5, Insightful)
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).
Yep (Score:2)
The current crop of "raster based" games don't look so bad to me. I doubt that ray tracing would add very much to a FPS.
Re: (Score:2)
Re:Not quite (Score:5, Interesting)
Considering a non-reflective ray traced world at 800x600 needs 320,000 rays to be cast to calculate an image, so 9,600,000 at 30fps, the claim of 450 million ray segments makes sense... thats 45+ per pixel at 800x600, which is a lot of reflections. Usually you'd limit the number to a fairly low because 100 deep reflections don't add noticable detail, especially in motion. Thats a lot of room for both refractive and reflective objects to be in the scenes.
Re:Not quite (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
Plus, as I said in my first post on this, you just don't need that level of accuracy or detail if you're
Re:Not quite (Score:5, Interesting)
There was a paper published a couple of years ago (at Eurographics?) about this. Each ray was independent, and would return a value at each intersection (i.e. you get the primary ray value quickly, and then refine it further with secondary, tertiary, etc ray data). When a ray was no longer lined up with a pixel, it was interrupted and terminated. This meant that you got a fairly low quality image while moving quickly, but a much better one when you let they rays run longer. I found it particularly interesting, since it completely removed the concept of a frame; each pixel was updated independently when a better approximation of its correct value was ready, giving a much better degradation.
rabbit rabbit rabbit (Score:4, Informative)
"Oh, blast. Rabbit, I seem to have forgotten my pocketwatch. May I borrow yours?"
Rabbit: I'm late, I'm late, I'm late...
---
anyway, if these technology becomes a reality in the 3-5 years and if I read the article right, the whole graphics architecture would change, there would only be a need for a super graphics processor and less need for too much memory and those graphics pipeline/shader thingies...
The reason that they might want it in a CPU is that, why have a separate add on GPU to handle the job while the CPU could do it alone by that time. You would then only need a "basic" video card that would just do the display.
Hmmm... could this be one of the reasons why ATI and AMD merged?
Quake 3: Raytraced (Score:4, Interesting)
http://graphics.cs.uni-sb.de/~sidapohl/egoshooter
Rumors are there's a q4 version on the way.
Re:Quake 3: Raytraced (Score:4, Informative)
Dammit, Tim (Score:2)
I'm a doctor, not a programmer...
Re: (Score:2)
If you can't beat them, obviate them! (Score:4, Interesting)
If they're having trouble, for staffing or other reasons, producing good GPU designs, then it would be pretty clever of them to revolutionize the industry AND capitalize on their CPU strengths in a single move. More power to them, I say. (More power = about 120 watts, I'm guessing.)
Won't happen soon. (Score:5, Informative)
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).
Re: (Score:3, Funny)
Re: (Score:3, Informative)
Re: (Score:2)
Huh?
Current tech essentially adds up to the game of the day being a showcase for whatever the latest buzzword technology from the GPU makers is that month. Look at the games that are out in the last 6 months. We've got "HDR" lighting now, so everything is so damned fake-shiny it makes you want to puke. If you rate glitz as highly as realism, well, I still wouldn't rate them the same. The hacks we pull for high performance 3D graphics today result in plastic
Re: (Score:2)
There are multiple techniques to "fix" hard shadows in a raytracer or a raster, although the "correct" way to do them involves pairing a raytracer with a global illumination model (something like photon mapping). They're just slow to compute. In general, you can make the raytraced ones look nicer, but they take longer the nicer you want them to look, of course.
2) You can fake it well enough for simple cases like water, or a single mirror. Although sometimes the la
Re: (Score:2)
And really, the only reason to raytrace is so that your artists don't need to make and optimize a million reflection and shadow maps
Re:Won't happen soon. (Score:5, Informative)
If you read the Intel paper that inspired TFA's author to write his ill-informed article, you'll see that raytracing scales better with scene complexity, and Intel did benchmarks to show that after about 1M triangles per scene, software raytracers will outperform hardware GPUs using triangle pipelines (e.g. openGL, directX, shaders).
Sure, once we get to the point where there's enough processing power to deal with this well enough in realtime, it will happen
The benchmarks in the Intel paper show that we are very close to that point right now.
What, are you new here? (Score:2)
Re: (Score:3, Interesting)
Sharp and straight shadows? Check out this example [povray.org] or this one [povray.org] or yet another. [povray.org] Granted, these scenes rendering times are measured in hours, not fractions of a second... but eventually games will be at that level of quality.
30 fps - unlikely (Score:5, Interesting)
Ray tracing also suffers terribly from "jaggies". Edges look bad because rays can just miss an object and cause really bad stepping on the edges of objects. To eliminate jaggies and do anti-aliasing, you need to do sub-pixel rendering with jitter (slight randomness) to produce an average value for the pixel. So you might have to trace 4 or more rays in a pixel for acceptable anti-aliasing. Effects like focal length, fog, bump mapping etc. cause things to get even more complex. Most pictures rendered with high quality on Blender, POVRay etc. would take minutes if not hours even on a fast / dual core processor.
The only way you'd get 30fps is if cut your ray trace depth to 1 or 2, used a couple of lights, cut the screen res down and forgot about fixing jaggies. It would look terrible. Oh and find time for all the other things that apps and games must do.
Re: (Score:2)
Re: (Score:2)
The Intel research paper that inspired TFA's author actually did benchmarks, and their scenes were pretty complex. Basically, raytracing's complexity scales with the log of the number of triangles in the scene, whereas the techniques currently used in GPUs scale l
Re: (Score:2)
Re: (Score:2)
Ray tracing also suffers terribly from "jaggies". Edges look bad because rays can just miss an object and cause really bad stepping on the edges of objects.
I know traditional ray-tracers solve this with an anti-aliasing pass, but I thought real-time ray tracers solved this by incorporating a radiacity engine instead.
Effects like focal length, fog, bump mapping etc. cause things to get even more complex. Most pictures rendered with high quality on Blender, POVRay etc. would take minutes if not hours eve
Use a moment method with physical optics (Score:2, Interesting)
Re: (Score:2)
Re: (Score:2, Funny)
Raytracing vs. Scanline for Realtime (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:2)
Film at 11 (Score:5, Insightful)
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.
Re: (Score:2)
Exact Shapes (Score:2)
Lies, Damned Lies and RT Raytracing (Score:5, Informative)
1) Static Objects Only. The huge majority of computation time is traversing a spatial subdivision structure. It happens that K-d trees offer the best characteristic (typically, fewest primitive per leaf for a given memory limit). However, these are really heinous to dynamically update. You can cheaply re-create it with median partitioning, but your trees are crappy. You can do a much nicer SAH (surface area heuristic), but to do this per frame blows out your CPU budget.
2) Bandwidth. Even if you could update your subdivision structure very cheaply, that structure still needs to be propogated out to all the CPUs participating in the raytrace. For the 1.87 MTri model they list on page 6, their spatial structure was 127 MB. Say you have a bandwidth of 6 GB/s, it takes 20ms just to transfer the structure (and there are other problems here). So your ceiling is 50 Fps before you trace your first ray.
3) Slower than a GPU. Even though they give you some little graph showing that raytracing (a static model, with static partitioning) beats a GPU at a MTri in the frame, this is very deceiving. The GPU pipeline works such that zillions of sub-pixel triangles simply can't get into pixel shaders fast enough, and force the pixel shader to be run many times extra. Double the resolution, however and the GPU won't take a cycle longer... with raytracing, performance will halve. So they found a bottleneck in the GPU which is totally unrepresentative of a game in every single sense, and said LOOK! BETTER! (in theory).
4) Hey, Where's my Features? All the cool things about raytracing (nice shadows, refraction, implicit surfaces, reflection, subsurface scattering) all get tossed out the window to make it real-time! What's the point, then? Given all the pixel shader hacks invented to make a GPU frame look interesting, the quality that can be achieved in a real-time raytrace is sadly tame. Especially when you consider that quality is the supposed advantage of raytracing.
And c'mon. It's Gameplay that counts anyway :P
Re: (Score:3, Interesting)
As for dynamic scenes, this is actually easier in many ways with a ray tracer. If you start with a scene graph API, you just need
Re: (Score:2)
But gameplay doesn't sell hardware. You've got a lot to learn about the modern gaming industry.
Although now that I think about it, I'd probably buy an "AI Coprocessor" if it meant better AI in games...
Three Words (Score:3, Informative)
Three or four people have brought up the idea that problem would work well for the cell processor. But I don't think anyone has really seen the (rays of) light on the issue. The Cell is perfect for this. Some facts:
1) Raytracing is highly vectorized. The Cell's many processors are optimized for vector calculations. [wikipedia.org]
2) Raytracing scales linearly with the number of cores. The Cell has 8 (at least in its current manifestation).
3) The Cell is already available [linuxdevices.com] as a PCI-Express add-in card (that even runs linux!) which sounds awfully like what a GPU is... 4) The Cell is a bitch to program. But then, so are GPUs...so maybe it's not that ridiculous to see the future of the GPU...from IBM.
How ironic it is that Intel is now pushing this technology...
Re: (Score:2)
I do not know how difficult cell is to program, but I can assure you that GPU programming is no harder than CPU programming (as long as you don't code your shaders in assembler of course).
Re: (Score:2)
No, you're getting it all wrong! This is Slashdot, where we collectively bash Sony for making a hugely expensive game console.... or praise Sony for selling a monster workstation ridiculously cheap.... I forget which way it is this week ;)
SGI Siggraph 2002 demo (Score:2, Informative)
http://www.sci.utah.edu/stories/2002/sum_star-ray. html [utah.edu]
They make some good points about geometric complexity increasing much faster than displayed pixels, so there are fewer graphics primitives per pixel, so scan-line-based algorithms will make less sense.
So in 2002 it took 128 processors to run at 20Hz at 512x512 pixels. And now we think quad-cores will be enough
More interesting to me... (Score:2)
I have seen comparatively weak, 1M gate FPGA's enc
Re: (Score:2)
Re: (Score:2)
So just like, say, a 3D graphics card then?
This was predicted in 1968 (Score:2)
Bogus Intel comment (Score:2)
Thats a bogus comment, as raytracing time (hence framerate) is totally dependent on the complexity of the scene being rendered.
E.g. A few simple cubes would raytrace MUCH faster than a forest scene with reflective water and multiple trees, leaves, and blades of grass etc.
Unfortunately, for gaming, the latter scenario is much more likely.
It still makes sense to o
How many do I need (Score:5, Funny)
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 (Score:5, Funny)
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*
Re: (Score:3, Funny)
Re:How many do I need (Score:5, Funny)
Yeah, but asteroids will look AMAZING!
Re: (Score:2)
Ah, but can you picture it in raytraced 3D? (Score:2)
I smell a winner. Let's now flood the review sites with 120 screenshots (see, in that one there are _two_ large asteroids)and we could have a bestseller.
Re: (Score:2)
Re: (Score:2)
Sure, you could get for free _most_ effects tha
Re:Ah, but can you picture it in raytraced 3D? (Score:4, Informative)
the default shader is, I believe, Lambert (a close relative to Phong - if not, it's Phong) for OpenGL and probably DirectX as well. Programs in the shader can change this to whatever you want it to be (e.g. a cel shader) and you would need to do that in either a ray tracer or rasterizer.
there's a lot of things I like about ray tracing, but it's not without flaw - it handles specular highlights fantastically, but doesn't handle diffuse well at all, so you have to bolt on other techniques. Most people (including Intel) use ambient occlusion since it's a quick technique (also commonly used in polygon based graphics), but it tends to make muddy shadows (see the wikipedia entry [wikipedia.org]). Radiosity [wikipedia.org] is more realistic, but the patch computations are incredibly expensive (but parallel-able). photon mapping [wikipedia.org] is another method that could be used, but I haven't used it myself. In college I wrote (with a team) a simple ray tracer and shortly after that class wrote a radiosity engine, so I'm familiar with both techniques. I never did really understand how to combine them, but I remember seeing POVRAY do it in the mid 90s and really wanted to figure out how they did it (but I graduated and was putting in startup hours, so that never happened).
Oh, and waves on a lake are non-trivial - to be completely realistic, you need to deal with subsurface diffusion (or estimation of), foam and caustics (if you can see through the semi-transparent water surface). The specular mirror effect would be nice, but I don't see true caustics from either a raytracer or a rasterizer (you'd need to use ray bars or cones, probably).
Re: (Score:2)
Re:How many do I need (Score:4, Insightful)
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.
Re: (Score:2, Funny)
Also, you'll probably need a Kandalf [overclockercafe.com] case to put it all in.
Re: (Score:3, Funny)
I see you're sensibly predicting the first game to use this rendering technology will be "Doom 4",
which still won't provide ducttape for the flashlight.
Re: (Score:3, Interesting)
A core for an idle process?
I am not an expert in OSes, I thought that the idle process just gave the CPU something to do while it waited for a working process (the idle just allowed the working to butt-in, whenever somethin came along).
Wouldn't creating a core just to do nothing be hardware bloat at its most obsurd?
Or am I showing my ignorance, just a bit too openly.
Re: (Score:2)
Well I hope so anyway.
Re: (Score:2)
Re: (Score:2)
The problem with your logic is that the effective performance of CPUs is doubling every 18 months, and the effective performance of GPUs is doubling every 12 months. This holds over a period as long as GPUs have been in production. In other words, it will always be less expensive to produce a rendered image on a GPU than on a CPU. Now, if you can invent some image calcu
Re: (Score:2)
Re: (Score:2)
And by the way, having a reduced instruction set and adding a ton of processors is exactly what a GPU is.
Not only that (Score:2)
1. GPUs are already massively parallel things. If you think of way back in the days of 1 pipeline GPUs and cards, each extra pipeline is, in a way, like an additional core. We're already at the point where cards act like a 16 or 24 core chip, for all practical reasons. (Or 4x that if you run two 7950 GTXs in SLI.)
Graphics problems are by definition massively parallel. They're essentially doing the same (simple) set of operations on many many pixels. Unlike CPUs where