Larrabee - Game Changer?

Mathinker

Wed Aug 06 00:15:16 -0700 2008

manage

> I can't decipher it adequately

I don't think that enough details have been released that anyone else can, yet, either. Intel's announcement links to a $-required article which I cannot justify buying, seeing as all of the interesting information in it will probably end up very, very, soon in various places on the web.

BTW, was the title of the post an intentional play on words? I rather doubt that the extra processing power (if any) of Larrabee is going to change the gaming experience dramatically.

Larrabee-Game Changer?

Matt Fulkerson

Wed Aug 06 06:39:15 -0700 2008

manage

There could be tough times ahead for Nvidia.  But for the consumer, I'm all in favor of any technology that does not require expensive graphics-only hardware.  That is, having a more capable chip for general purpose computing that also happens to be good enough for video is a big plus.

Larrabee-Game Changer?

David Leppik

Wed Aug 06 10:57:02 -0700 2008

manage

Larabee is a bunch of simple, general-purpose processors (or "cores" if you prefer) connected with a high-speed bus on a single chip. It's very similar to the IBM Cell processors used in the Playstation 3. One of the biggest differences, and I think it's pretty minor, is that each Larabee processor is x86 compatible. Think of it as an add-on card that provides a bunch of 386s for tasks that can be done in parallel.

Intel will be shipping Larabee with 3D rendering software so you can run your DirectX and OpenGL programs using its processors rather than a special-purpose 3D card. They will be selling it initially as a graphics card, and it will likely be slower than the special-purpose graphics cards sold by its competitors. Why? Given the same number of transistors and power requirements, special purpose designs are faster than general purpose, typically by a factor of 10.

In Intel's favor, the trend in graphics cards has been toward more general-purpose processing. Larabee and Cell are at the extreme of this trend. For example, Nvidia cards no longer "cheat" when doing floating-point operations, meaning that their calculations are up to IEEE standards. (If you're just putting pixels on the screen, rounding errors usually don't matter.) And both IBM and Nvidia are celling supercomputing co-processors based on (IBM's) Cell and (Nvidia's) GPUs.

Intel is also hoping that video game developers will switch from OpenGL and DirectX graphics libraries to real-time ray tracing. Since only Larabee is designed with ray tracing in mind, developers would have to spend a significant amount of effort on Intel-specific development. (OpenGL and DirectX are polygon rendering libraries you program on top of, ray tracing is a type of algorithm, and one that is as different from polygon rendering as general relativity is to Newtonian physics.)

One big wildcard is Apple, which has a close relationship with Intel and might be willing to optimize Mac OS X for Larabee. Indeed, GrandCentral, a GPU-utilizing library, is scheduled to arrive with the next version of OS X-- about the same time as Larabee.

For this sort of news, I always rely on Jon Stokes at Ars Technica, who did his own write-up on this press release.

Larrabee-Game Changer?

Charles E Hill

Wed Aug 06 11:57:01 -0700 2008

manage

Ray tracing can be used to generate light maps and textures, which can then be applied via OpenGL.  It can easily be implemented as a separate layer, and frequently is.  Raytracing is a waste of processing power and time if you don't have any reflective or refractive surfaces.

Ray tracing

David Leppik

Wed Aug 06 14:55:48 -0700 2008

manage

You're largely right, but there's a lot more to it than just what you described. It's common to use ray tracing at game development time to precompute shadows, reflections, and complicated lighting. When you run the game, texture maps are applied to surfaces much as a movie projector applies an image to a screen. It's not a bad first-order approximation, but it means that nothing that happens within the game changes the image. So if you're using ray tracing to generate shadows, none of the characters in the game will cast shadows.

Ray tracing is the generic term for any algorithm that follows light rays through a scene. Beyond the traditional shadows, reflection, and refraction, it can also be used to accurately model fog. In particular, fog of varying thickness within a scene, and the cones of light from a flashlight on a foggy night.

There are all sorts of tricks and workarounds to get ray tracing effects without resorting to ray tracing, and they've been used to good effect for years. In fact, until Cars, Pixar didn't use ray tracing for any of its movies. [Technical paper from Pixar. Particularly interesting how they use ray tracing as a cheap alternative to radiosity.] Plus modern video games can do quite a few simplified ray tracing effects using a GPU.

At some point it becomes computationally easier just to do ray tracing. The advantage for polygon-based rendering such as OpenGL comes when you can convert your 3D objects into a relatively small number of polygons. But the more complicated your scene, the less of an advantage there is.

If you're drawing a huge ball onto your high-definition (1920x1080) display, the ray tracing program to generate that is trivial. You just plug in the mathematical definition of a sphere. (A point and a radius.) To generate that in OpenGL, you convert the sphere into enough polygons to look good on your display. If you figure about one polygon for every 16 pixels on your screen, you need to render 130,000 polygons. All else being equal, ray tracing is the easier computation in that case.

Ray tracing

Charles E Hill

Wed Aug 06 15:04:42 -0700 2008

manage

If you're drawing a huge ball onto your high-definition (1920x1080) display, the ray tracing program to generate that is trivial. You just plug in the mathematical definition of a sphere. (A point and a radius.) To generate that in OpenGL, you convert the sphere into enough polygons to look good on your display. If you figure about one polygon for every 16 pixels on your screen, you need to render 130,000 polygons. All else being equal, ray tracing is the easier computation in that case.

Except I don't know one game engine that does honest-to-goodness solid object geometry.  The equations for doing a ray intersecting with an arbitrary curve, such as a sphere, are hellacious compared to the intersection of a ray and a plane (triangle).

I've never really been convinced that ray tracing shadows was any benefit.  Shadow mapping has always been cheap, fast and quite good.  Ray traced shadows were fine in space, but the sharp edges were abnormal in the real world.  You need to fuzz the edges to account for diffusion and light scatter, which sort of defeats the purpose.

As far as nothing changing in the game while the raytracing is being computed to be mapped... I thought that was the point of hardware acceleration of both.  The computation and mapping are faster than 30 fps, allowing for faster-than-realtime rendering and thus proper double bufferening for smooth animation.

Or am I missing something?

Ray tracing

David Leppik

Thu Aug 07 12:15:15 -0700 2008

manage

Except I don't know one game engine that does honest-to-goodness solid object geometry. The equations for doing a ray intersecting with an arbitrary curve, such as a sphere, are hellacious compared to the intersection of a ray and a plane (triangle).

None of them do, because they rely on the graphics card to have highly optimized triangle rendering hardware. But Larabee levels the playing field for ray tracing.

As for the formulas, with ray tracing you want to know the distance along a ray for the first intersection. (You consider at least one ray per pixel, which corresponds to a light ray that intersects both your eye and the pixel on the screen.) For a sphere, that involves a small number of multiplies and compares. [Formula] (Note: that formula uses a square root, which you can avoid by squaring the other side of the equation.) For a plane, it's slightly easier. Triangle intersection involves first finding the intersection with the triangle's plane and then three more plane intersections to see if you are within the triangle's bounds. They are all really fast calculations, with the plane being the fastest and the triangle being the slowest.

On the other hand, the scanline algorithm used by graphics cards involves computing the position of each edge of a triangle (which can be done with little more than a 4x4 vector multiply for each point, once you've precomputed the camera position and other geometric transformations). At that point you have converted the 3D data into 2D lines and polygons, for which there are fast, age-old algorithms for drawing them. Scanline algorithms are much more complicated than ray tracing, but it's really fast as long as you have far more pixels than polygons.

I've never really been convinced that ray tracing shadows was any benefit. Shadow mapping has always been cheap, fast and quite good. Ray traced shadows were fine in space, but the sharp edges were abnormal in the real world. You need to fuzz the edges to account for diffusion and light scatter, which sort of defeats the purpose.

Sharp edges are what you get when you assume a point light source. Fuzzy edges are easy to compute if you throw more rays at the problem. If you want really realistic shadows, you can use a technique known as radiosity. But that's far more computationally expensive than ray tracing. (In Cars, Pixar used a ray tracing based technique as a poor man's radiosity.)

Ray tracing

Charles E Hill

Thu Aug 07 12:39:45 -0700 2008

manage

Well, you're sort of cheating.  A sphere, like a plane, is a special case because the curve is a simple, predicatable equation.  That's partly my fault for using the phrase "arbitrary curve, such as a sphere".  Things get much more computationally intensive when it really IS an arbitrary curve instead of (x-c)²=r².

I can see where ray tracing can be expanded to handle quadratic curves without too much difficulty, but arbitrary curves are going to provide a serious headache.  I'm also thinking of clipping when you intersect an arbitrary curve with, well, any other object.  Not that games do a fantastic job at that now...

Of course, the whole "non-planar polygon" issue would go away, which is a plus.

I'm familiar with radiosity, and it would be interesting to see hardware acceleration for that.  My experience was as an animator for an independent production house at Universal and Nickelodeon down in Orlando.  Mostly Lightwave 3D, from v0.9 thru about 6.5, and then some Renderman.