[hinkley]

I read Practical Parallel Rendering (1st Edition: 2002) quite a long time ago, on someone's recommendation. There's quite a substantial section on how to build and manage effective job queues that's worth a read even if you don't do any CGI.

But there's also a thesis in there: given that scene descriptions grow in size much faster than screen resolution increases, there should be a tipping point where ray-tracing is more efficient than rasterization. I don't think they expected it to take quite this long though.

[corysama]

"Practical Parallel Rendering" is a great book for anyone. It really is "Parallel Work Distribution Options: The Book".

The argument that "Ray tracing is logarithmic in scene complexity while rasterization is linear. Therefore, ray tracing will win eventually!" ignores the fact that rasterizers also use hierarchical graphs to maintain logarithmic complexity just like ray tracers do. You could make the same argument if you compared a well-designed rasterization-based system vs. a naive ray tracer that brute-forces every triangle vs. every pixel.

The difference is really a focus on local vs. non-local data. Rasterizers focus on preparing data ahead of time so that it can be directly indexed without searching. Ray tracers focus on making global searching as fast as possible. Rasterizers do more work at the start of a frame (rendering shadow, reflection, ambient occlusion maps). Ray tracers do more work in the middle of the frame (searching for shadowing/reflecting/occluding polygons).

It's wonderful that we finally have both accelerated in hardware. HW ray tracing still has a very long way to go. Currently, budgets are usually less than 1 ray per pixel of the final frame in real time apps! Figure that out how to use that effectively! :D But, it still opens up many new possibilities.

[pixelpoet]

I (lycium) wrote a bunch on this topic on a recent thread on reddit r/hardware, with many similar points: https://www.reddit.com/r/hardware/comments/enn41z/when_do_yo...

[sitkack]

Isn’t < 1 day per pixel totally ok because of the DNN denoising kernels? One could even train the de loser on offline computer frames indicative of the specific scenes.

[Arelius]

Yes, so the primary test, "Does this triangle cover this pixel" is the same between rasterization and ray-tracing. So the fundamental difference is the outer loop.

Rasterization goes for each triangle, which pixels does this intersect, whereas for ray-tracing it's for each pixel which triangles does this intersect.

Clearly, this allows us to build lookup data structures over the inner loop. So back of the hand ray-tracing becomes more efficient when you have more triangles than pixels (give or take an order of magnitude or so due to algorithmic differences)

So, the complexity of real-time content development has slowed due to multiple of reasons, not the least of which being that rasterization (especially modern GPU rasterization with quad based shading) is poorly suited to scenes where polygons approach pixels in coverage. And more importantly, we've hit the polygon density where we appear to be getting better visual quality gains by spending cycles on improved shading rather than more polygons.

Then add in the transition to 4K and we get a much larger pile of pixels once again changing the math all over again.

I don't know what this means for the future. I suspect we won't see much increase in scene complexity until we get to the cliff where ray-tracing is then viable, then I imagine scene complexity for real-time scenes will make a big jump.

Keep in mind, what you read is with offline CGI in mind. And we've already hit that tipping point for offline rendering. Even the last major rasterization hold-out (PRMAN) has switched to path-tracing even primary rays. It's just that real-time rendering is a bit of a different beast.

[Jasper_]

Rasterization has some niceties for things like cache coherency. Since you're rasterizing a triangle at a time, all with the same shaders, textures, and buffers, SIMD techniques used in GPUs is very effective. But when you have ray-tracing, any ray can hit any triangle. If you cast 64 rays and each one hits a different triangle, you lost your entire parallelism. You possibly have to give up on SIMD if the material models between the triangles are different.

For this reason, and for the reason of real-time ray budgets barely approaching 1 ray per pixel at 1080p on the highest cards, ray-tracing tends to mostly be used for specular effects at this time.

Even in non-real-time workloads, this was a massive time sink until ray sorting and batching entered the common practice, collecting rays that hit a single coherent area to be processed at once. And the current RTX model has no strong support for ray batching.

[windoze]

I would have thought that for physically based shaders, most polygons are the same shader with different material parameters, wouldn't that allow SIMD techniques to continue to work?

[inferiorhuman]

there should be a tipping point where ray-tracing is more efficient than rasterization

In a previous life I worked for a company that was developing real-time ray tracing products. The founders had this magical algorithm but the catch was that dedicated ray tracing hardware was almost never successful because by the time the dedicated hardware made it to market general purpose processors had caught up.

However, what it seemed like to me was that the founders had developed a blazing fast algorithm that cut a ton of corners. Each time they'd fix an edge case the product got slower. Regardless they were moderately successful and might still be around.

And then there was the time I accidentally nuked all of our internal infrastructure in the middle of a product release demo.

[cuu508]

> However, what it seemed like to me was that the founders had developed a blazing fast algorithm that cut a ton of corners.

No idea if it's your company, but this bit sort of reminds me of Euclideon demos: https://www.youtube.com/watch?v=DrBR_4FohSE

[inferiorhuman]

Nope that's a different company.

[mschuetz]

> there should be a tipping point where ray-tracing is more efficient than rasterization.

How so? Wouldn't both scale logarithmically with respective hierarchical acceleration structures? In what way does ray tracing scale better?