Larrabee to also be presented at Hot Chips

Friday 13th June 2008, 11:24:00 PM, written by Arun

Since the rest of the internet is still at the stage where they're all excited about Larrabee being presented at Siggraph (hint: you guys are ten days late), we thought we'd let you know it will also be presented at Hot Chips, presumably with more of a hardware perspective.

We hope Intel will actually dare to make their strategy clear at these two events, especially when it comes to rasterisation vs raytracing, developer evangelism, and DirectX 11. Let's make one thing clear: there's no real difference between the current ray tracing stratagems of Intel and NVIDIA, or what will come out when the end games of both are presented.

The implementation details of how they want to make raytracing fast may vary, but both see it is as a very important research project that should not, however, be applied too much too fast. It is amusing how it seems that NVIDIA thinks Intel takes raytracing more seriously than they really do, while Intel thinks the same for NVIDIA with rasterisation. As is true about many parts of the semiconductor industry and life in general, the truth is often in the middle.


Discuss on the forums

Tagging

intel ± larrabee, hotchips


Latest Thread Comments (18 total)
Posted by nAo on Monday, 16-Jun-08 03:39:59 UTC
Quoting TimothyFarrar
My bet is that ray tracing will be much faster on NV hardware, and that NV is targeting the movie/commercial/in-game-video ray tracing market.
Do you know something we don't?

Quote
As for real-time ray tracing, about all that is needed for current raster based hardware is a fast hardware path for writing depth conditional that written depth is farther away from eye than the triangle primitive's depth. Then HiZ (AMD) Z-Cull (NV) could still work without much of a hardware change. Simply raycast into the triangle, and use triangles as bounding geometry to accelerate the raycast. Writing depth is required to solve overlap problem else you get billboards... Solve secondary rays with traditional image space maps (cubemaps, etc). Hybrid methods will be practical very soon (next console generation).
Umh..dunno, triangles don't sound too exciting as accelerating structure.

Posted by TimothyFarrar on Monday, 16-Jun-08 15:54:41 UTC
Not one map per triangle (obviously). Think of maps as simply a way to pool secondary rays by data locality. Don't forget that you can raycast into a map also.

Quoting nAo
Do you know something we don't?
Just speculation for now...

Quote
Umh..dunno, triangles don't sound too exciting as accelerating structure.
Why not? Triangles can solve rough visibility without searching, then leave fine searching for a fragment shader. Stop thinking about triangles as actual surfaces, and begin thinking of them just as bounding volumes in combination with a good level of detail and hierarchical occlusion system.

How would a traditional ray tracer have any hope in accelerating a really dynamic system with a lot of moving objects? Rebuilding the acceleration structure which is necessary to get good ray search performance would be many times more expensive than simply rendering the bounding volumes of the movers (ie leaves of a tree, etc) to start the rays from. Somewhat similar to the reason we radix sort instead of quick/heap/merge sort...

Posted by MfA on Monday, 16-Jun-08 16:13:54 UTC
Quoting TimothyFarrar
Not one map per triangle (obviously). Think of maps as simply a way to pool secondary rays by data locality.
Secondary rays and data locality? That's a good one ;)

Doing a hybrid between object order and image order rendering will only work for the primary and shadow rays ... if rays don't originate from a single point the only way to know if there is an intersection is to do the test per ray.

Posted by nAo on Monday, 16-Jun-08 18:08:00 UTC
Quoting TimothyFarrar
Why not? Triangles can solve rough visibility without searching, then leave fine searching for a fragment shader. Stop thinking about triangles as actual surfaces, and begin thinking of them just as bounding volumes in combination with a good level of detail and hierarchical occlusion system.
I think you answered your own question :) Triangles are not exactly the best accelerating structure and you want to use them to perform part ray traversal and as you say you'd still need to a structure to speed up the rest of your traversal.

BTW..I know it's semantics but I wouldn't say that triangles solve visibility without searching: you are still searching, just in a different way.
Andy put this very well in a long post he wrote on another forum, too bad I can't find it now :)

Quote
How would a traditional ray tracer have any hope in accelerating a really dynamic system with a lot of moving objects? Rebuilding the acceleration structure which is necessary to get good ray search performance would be many times more expensive than simply rendering the bounding volumes of the movers (ie leaves of a tree, etc) to start the rays from. Somewhat similar to the reason we radix sort instead of quick/heap/merge sort...
You'd still need to (re)build the 'rest' of your accelerating structure, unless you complete structure (triangles + something else) naturally handles rigid transforms.

Posted by TimothyFarrar on Monday, 16-Jun-08 18:27:02 UTC
Quoting nAo
BTW..I know it's semantics but I wouldn't say that triangles solve visibility without searching: you are still searching, just in a different way. Andy put this very well in a long post he wrote on another forum, too bad I can't find it now :)
Yeah, in terms of hierarchical occlusion culling/lod you are limiting your "search" with temporal locality and log cost pre-Z drawing pass.
Quote
You'd still need to (re)build the 'rest' of your accelerating structure, unless you complete structure (triangles + something else) naturally handles rigid transforms.
Yes the "something else" and rest of the traversal, I'm purposely leaving it out here. Without giving out all the details: hint not triangles, doesn't need to get rebuilt, and yes does work with rigid transforms.

Posted by nAo on Monday, 16-Jun-08 18:32:14 UTC
Quoting TimothyFarrar
Yeah, in terms of hierarchical occlusion culling/lod you are limiting your "search" with temporal locality and log cost pre-Z drawing pass.
I see, but let say I want to compute some dynamic ambient occlusion terms (no screen space hacks please..) ? ;)
Quote
Yes the "something else" and rest of the traversal, I'm purposely leaving it out here. Without giving out all the details: hint not triangles, doesn't need to get rebuilt, and yes does work with rigid transforms.
You are a good teaser :)

Posted by TimothyFarrar on Monday, 16-Jun-08 23:27:03 UTC
Humm, I'm wrong, actually apparently on at least one current platform you can force coarse tile raster z culling with depth writes on if writes are farther than triangle plane equation Z.Anyway as per 2ndary rays using maps, http://www.fsz.bme.hu/~szirmay/ibl3.pdf, its not as if this hasn't been done before (just GPU performance hasn't been there to do it yet).

Posted by MfA on Tuesday, 17-Jun-08 00:25:30 UTC
Quoting TimothyFarrar
Anyway as per 2ndary rays using maps, http://www.fsz.bme.hu/~szirmay/ibl3.pdf, its not as if this hasn't been done before (just GPU performance hasn't been there to do it yet).
If this is raytracing then so is parallax mapping. I'd sooner call this kind of environment map hack rasterization myself (also Franklin Seung-Hoon Cho described this method half a decade before they did, see "Towards Interactive Ray Tracing in Two- and Three-Dimensions").

Posted by TimothyFarrar on Tuesday, 17-Jun-08 16:22:48 UTC
Quoting MfA
If this is raytracing then so is parallax mapping. I'd sooner call this kind of environment map hack rasterization myself (also Franklin Seung-Hoon Cho described this method half a decade before they did, see "Towards Interactive Ray Tracing in Two- and Three-Dimensions").
Sure, from parallax mapping to cone tracing, all fragment shader ray tracing with different amounts of quality / cost trade-off in the ray intersection test, and different acceleration structures. Personally I don't see a good idea in doing triangle intersection tests at the pixel level, takes too long, costs too much memory to store the triangles and what is required to shade those triangles, and doesn't work well in terms of LOD or antialiasing. Time to think outside the triangle.

Posted by MfA on Wednesday, 18-Jun-08 02:38:52 UTC
Raycasting into rasterized environment maps will not be what people expect when you say you are raytracing on the GPU. Most of the heavy lifting is still done by rasterization and you have none of the elegance or generality of what people will expect from raytracing.Also if you want to do it right you simply can't leave it at that, because of differences in occlusion from the original point of view and that of the actual ray you will get artefacts ... for refraction and lighting effects it's not so bad because we have a higher tolerance for errors there, but reflections will be noticeably fucked up on occasion. You can make a good guess where the artefacts are and fill them in with real raytracing, but then you actually have to be able to do real raytracing.


Add your comment in the forums

Related intel News

Analysis: Intel-TSMC announcement more complex than reported
Intel and TSMC join forces to further Atom
Fudzilla: Intel 45nm Havendale MCM replaced by 32nm+45nm MCM
Intel announce Core i7 processors, reviews show up
Intel's Aaron Coday talks to Develop about Larrabee
Intel Larrabee @ SIGGRAPH 2008
Larrabee's Rasterisation Focus Confirmed
Nehalem Article @ RWT + 3.2GHz samples(?)
Opinion: Silverthorne fails but PowerVR impresses (+Montalvo trouble)
Belated Analysis: Intel Atom/Silverthorne