Now that we've made a point of deflating certain myths associated with ray tracing, let's look at the real issues that the technique involves.

We'll start with the major problem associated with the rendering algorithm: its slowness. Of course, there are those who'll say that that's not really a problem, since, after all, ray tracing is highly parallelizable and with the number of processor cores increasing each year, we should see nearly linear increases in ray tracing performance. And what's more, research on the optimizations that can be applied to ray tracing is still in its infancy. When you look back at the earliest 3D cards and compare them to what's available today, you might tend to be optimistic.

However, that point of view misses an essential point: the real interest of ray tracing lies in the secondary rays. In practice, visibility calculation using primary rays doesn't really represent any improvement in image quality over a classic Z-buffer algorithm. But the problem with these secondary rays is that they have absolutely no coherence. From one pixel to another, completely different data can be accessed, which cancels out all the usual caching techniques that are essential for good performance. That means that the calculation of secondary rays becomes extremely dependent on the memory subsystem, and in particular on latency. This is the worst possible scenario, because of all memory characteristics, latency is the one that has made the least progress in recent years, and there's no indication that's likely to change any time soon. It's easy enough to increase bandwidth by using several chips in parallel, whereas latency is inherent in the way memory functions.

The reason for the success of GPUs is that building hardware dedicated to rasterization was an extremely effective solution. With rasterization, memory access is coherent, regardless of whether it involves access to pixels, texels, or vertices. So, small caches coupled with massive bandwidth were ideal for achieving excellent performance. Bandwidth is computationally expensive, but at least it's a feasible solution if the economics justify it. Conversely, there just aren't any solutions for accelerating memory access with secondary rays. That's one reason why ray tracing will never be as efficient as rasterization.

Another intrinsic problem with ray tracing has to do with anti-aliasing (AA). The rays being shot are in fact simple mathematical abstractions and have no actual size. Consequently, the test for intersection with a triangle returns a simple Boolean result, but it provides no details, such as "40% of the ray intersects this triangle." The direct consequence of that is aliasing.

Whereas with rasterization it was possible to dissociate shader frequency from sampling frequency, it's not that simple with ray tracing. Several techniques have been studied to try to solve this problem, such as beam tracing and cone tracing, which give the rays thickness, but their complexity has held them back. So the only technique that can get good results is to shoot more rays than there are pixels, which amounts to supersampling (rendering at a higher resolution). Needless to say, that technique is much more computationally-expensive than the multisampling used by current GPUs.