CausticOne and the Initial Strategy
Out of the gate, Caustic isn't going after gaming. They aren't even going after the consumer market. Which, we think, it quite a wise move. Ageia showed very clearly the difficulty that can be experienced in trying to get support for a hardware feature that is not widely adopted into games. Game developers only have so many resources and they can't spend their time on aspects of game programming that completely ignore the vast majority of their users. Thus, the target for the first hardware will be in film, video and other offline rendering or simulation areas.
The idea isn't to displace the CPU or the GPU in rendering or even raytracing specifically, but to augment and assist them in an application where rays need to be cast and evaluated.
The CausticOne is a board built using FPGAs (field programmable gate arrays) and 4GB of RAM. Two of the FPGAs (the ones with heatsinks on them) make up SIMD processing units that handle evaluation of rays. We are told that the hardware provides about a 20x speedup over modern CPU based raytracing algorithms. And since this hardware can be combined with CPU based raytracing techniques, this extra speed is added on top of the speed current rendering systems already have. Potentially, we could integrate processing with CausticOne into GPU based raytracing techniques, but this has not yet been achieved. Certainly, if a single PC could make use of CPU, GPU and raytracing processor, we would see some incredible performance.
Caustic Graphics didn't go into much detail on the processor side of things, as they don't want to give away their special sauce. We know it's SIMD, and we know that it is built to handle secondary incoherent rays very efficiently. One of the difficulties in building a fast raytracing engine is that as you look at deeper and deeper bounces of light, we find less coherence between rays that have been traced back from the eye. Essentially, the more bounces we look at the more likely it is that rays near each other will diverge.
Speeding up raytracing on traditional hardware requires building packets of rays to shoot. In packets with high coherence, we see a lot of speed up because we reuse a lot of the work we do. Caustic Graphics tells us that their hardware makes it possible to shoot single rays without using packets and without hurting performance. Secondary incoherent rays also don't show the same type of performance degradation we see on CPUs and especially GPUs.
The CausticOne has a huge amount of RAM on board because, unlike with the GPU, the entire scene needs to be fully maintained in the memory of the card in order to maintain performance. Every ray shot needs to be checked against all the geometry in a scene, and then secondary rays shot from the first intersection need to have information about every other object and light source. With massive amounts of RAM and two FPGAs, we know beyond a shadow of a doubt that Caustic Graphics' hardware must be very fast at branching and very adept at computing rays once they've been traced back to an object.
Development is ongoing, and the CausticOne is slated to go to developers and those who run render farms. This will not be an end user product, but will be available to those who could have a use for it now (like movie studios with render farms or in High Performance Computing (HPC, or big iron) systems). Developers of all kinds will also have access to the hardware in order to start developing for it now before the consumer version hits the streets.
Their business model will be service and support for those who want and need it with CausticOne. Caustic Graphics has extended OpenGL ES 2.0 with GLSL to include support for shooting rays from shaders. They hope that their extensions will eventually become part of OpenGL, which may actually be useful in the future especially if hybrid rasterizing and raytracing rendering engines start to take off. They went with the ES spec, as it's less encumbered by legacy elements present in OpenGL.
On top of OpenGL ES 2.0 with Caustic's extensions, developers can use the CausticRender package which is a higher level set of tools designed on top CausticGL (which is what they're calling their extended GL API). This allows developers to either dig down to the low level or start writing engines more intuitively. There are more tools that Caustic is working on, and they do hope to see content creation ISVs and others start building their own tools as well. They want to make it easy for anyone who already has a raytracing engine to port their software to a hardware accelerated version, and they also want people who need to render raytraced scenes to have software that can take advantage of their hardware.
Focusing on developers and render farms first is a great way to go, as it sort of mirrors the way NVIDIA used the HPC space to help get CUDA exposure. There are applications out there that never have enough power, and offering something that can provide an order of magnitude speed up is very attractive in that space. Getting software support in the high end content creation and rendering packages would definitely help get Caustic noticed and possibly enable them to trickle down into more consumer oriented markets. But that brings us to next year and the CausticTwo.
Facebook
Twitter
RSS
48 Comments
View All Comments
ssj4Gogeta - Monday, April 20, 2009 - link
I'm no pro, but from what I know the main difference is that things like shadows, refractions and reflections render MUCH better. This is because in raytracing you also use secondary rays. So the rays reflected off/refracted from a surface can affect the color of other nearby surfaces, producing shadows, reflections, etc. In ray tracing you do it just like nature does it in real world (in reverse of that, but that doesn't affect the outcome). In rasterization, you need to manually program for producing shadows, reflections, etc. and so they are mostly just approximations.Another advantage of ray tracing is that programmers don't need to work that hard - things which may take you hundreds of lines of code in rasterization, only take 10 lines in ray tracing.
Compare this to 3D vs 2D rendering of a 3D cube. Suppose you need to render the cube as the camera circles around it. If you're doing it in 3D, you just render it in 3D, flatten the image and display it. Now if you're using 2D, but you want to create the effect of 3D, you don't have to render a cube - you need to directly render how the flattened image would look. That is, you need to take into account the 3D distortion due to perspective/depth and you need to make the edges of the cube oblique accordingly, you need to make the part of the cube that is farther look farther by rendering it smaller than the face of the cube that is closer to the camera. A lot of work for the programmer, and needless to say, it won't be very accurate. Well in this case it may be accurate as it's just a cube with straight edges, and so you can easily calculate things. But not in the case of a complex object.
Same way, rasterization at best can offer approximations of phenomena like refraction etc., how close they are depend on the programmer.
Check this rendered pic to see what ray tracing can deliver:
http://upload.wikimedia.org/wikipedia/commons/e/ec...">http://upload.wikimedia.org/wikipedia/commons/e/ec...
Note: I'm not a graphics programmer but this is how I understand it. Please correct me where I'm wrong.
AmbroseAthan - Wednesday, April 22, 2009 - link
That picture is a ray-traced rendering?! It looks like a photograph! Someone put in a lot of time and crunching power on that one.JimmiG - Monday, April 20, 2009 - link
I'm also wondering about #2 - is Raytracing really "better", or just "different"?Back in the 90's I used to be really impressed with the quality of raytraced animations and pictures, with their shiny, reflective objects, realistic water, lighting, soft shadows etc. However back then the capabilities of "3d accelerators" were very limited - 3d games used simple models, "flat" lighting models with no shadows and only one light source, and blurry textures without any shader effects like bumps, parallax maps, reflections etc. Today it seems the latest 3d engines already do everything in realtime that you needed raytracing and many minutes/hours per scene to do in the past.
jimhsu - Monday, April 20, 2009 - link
Someone correct me, but i think it is not that raytracing "looks" better, but because it is closer to a physical description of light (only in inverse), effects such as ambient occlusion, caustics, and other shiny things can be implemented in a relatively straightforward manner in a physically correct manner, while rasterization requires the use of shaders to "emulate" reality. These approximations are often complicated to program and implement, even though they achieve nearly the same effect.DerekWilson - Tuesday, April 21, 2009 - link
this is sort of true ... it's possible to write shaders for a rasterizer that do everything a raytracer does. But in addition to the code complexity in a z-buffer based rasterizer you end up with performance disadvantages.At the point where you properly and accurately emulate raytracing with a rasterizer you need to start generating all kinds of dynamic environment maps every frame for every object. treating objects as light sources and doing real time radiosity for rasterization (which can be done as well) is also difficult. To get an image that is as physically accurate as raytracing, rasterization (at this point with todays technology) would be slower even using a GPU designed for rasterization.
Honestly, there are some things that rasterization can approximate well enough that we don't notice the difference, and I think for a long time to come we'll still see rasterization as the main vehicle for realtime graphics. I think we'll start to see raytracing come in as a secondary tool to augment rasterization and add effects that are tough to achieve otherwise.
lopri - Tuesday, April 21, 2009 - link
I think I am learning more abou raytracing from this article and comments than anywhere else to date. Thank you for excellent explanations and analogies!jimhsu - Monday, April 20, 2009 - link
An analogy for math majors would probably be trying to solve a function analytically (i.e. rules of calculus) vs. numerically (i.e. Newton's Method, Euler, etc). The numerical result is often close to the analytical result, but intuitively the analytical result is the "right" way to do the problem, except when it is infeasible (we have something that we can't integrate).Einy0 - Monday, April 20, 2009 - link
This may actually help Larrabee gain ground. An alternative to do realtime raytracing. Then again Larrabee may help this gain ground as Larrabee will be do both rasterizing and raytracing.I'm surpirsed they can make anything worth buying with FPGAs. I guess FPGAs have come a long way. I'd love to get some specifics on the underlying architecture.
Bad timing considering the global economy etc...
ifkopifko - Tuesday, April 21, 2009 - link
lol... real-time raytracing? Keep dreaming. :-D Something like that is far far in the future.Sivar - Tuesday, April 21, 2009 - link
There have been assembly language demos from the 4k scene which have done realtime ratracing since the late 90's. In software. On a Pentium MMX.They aren't quite what I'd call Pixar-quality, but it's far from impossible.