Quote:Original post by ApochPiQ
It is not yet clear whether or not current GPUs will be able to hybridize sufficiently to do both scanline rasterization and practical raytracing on single hardware, but definitely expect RTRT (and, far more importantly, RTGI) to appear from the video card people, not the CPU people.

It is pretty clear on what is going to happen next with raytracing.
The largest hurdle and timesink when it comes to raytracing is the raytest, the actual code/hardware that tests a ray against the geometry, this is the only thing that differs between scanline rasterisation and raytracing, and there is no problem combining them(just look at the lightwave renderer).
In fact this raytest stage can be achieved with a surprisingly small amount of code on the GF8800, even though it will be faster than on any cpu(besides perhaps cell) it would still be slow.
That is unless you have specialized hardware for it.
If you look at what the SaarCOR people did, they used a modified memory design with many small sub processors to do this, let's call them SPPU(Single Purpose Processing Unit).
Now if you take thousands of these tiny raytest SPPU's, each with a few bytes of memory(to store geometry) and put them in a massive parallel grid processing array, then maybe you could get enough speed so that a raytest would sort of equal the speed of a texture lookup, and if you have that tied to a fragment shader then you have a true raytracing capable card.

Quote:Original post by lc_overlord
It is pretty clear on what is going to happen next with raytracing.
The largest hurdle and timesink when it comes to raytracing is the raytest, the actual code/hardware that tests a ray against the geometry, this is the only thing that differs between scanline rasterisation and raytracing, and there is no problem combining them(just look at the lightwave renderer).
In fact this raytest stage can be achieved with a surprisingly small amount of code on the GF8800, even though it will be faster than on any cpu(besides perhaps cell) it would still be slow.
That is unless you have specialized hardware for it.
If you look at what the SaarCOR people did, they used a modified memory design with many small sub processors to do this, let's call them SPPU(Single Purpose Processing Unit).
Now if you take thousands of these tiny raytest SPPU's, each with a few bytes of memory(to store geometry) and put them in a massive parallel grid processing array, then maybe you could get enough speed so that a raytest would sort of equal the speed of a texture lookup, and if you have that tied to a fragment shader then you have a true raytracing capable card.

Too many people focus on simple geometry intersection as if it mattered. Geometry hit tests aren't a big deal; there have been reliable RT-on-GPU implementations since the first Shader Model 2 hardware became available. Obviously raytracing can be done on GPUs with the current structure. Simple ray-casting techniques are already done as a matter of course in programmable shaders. There are even rudimentary global illumination solutions available.

Raytracing can also be done on my calculator and my cell-phone. That does not mean that those architectures are optimal.

It is certainly not yet clear whether or not the existing GPU architecture is optimal. A competitive, practical, marketable raytracing product would need to be heavily programmable, and support far more than simple Whitted-style tracing. In fact I would go so far as to say that without a realtime global illumination solution there is no point in deploying raytracing-centric hardware at all, because scanline rasterization in combination with programmable shaders is sufficiently powerful to outdo any Whitted-style renderer.

The problem is that RTGI is still a fairly unexplored domain. Raytracing itself is quite well understood, but we have a rather less thorough understanding of the possible GI algorithms and how to make them scale both in space and time.

Raytracing-based photon mapping methods have been done on the GPU for years already, but one of the persistent questions is if the memory requirements (in terms of access patterns and throughput) of RTGI and rasterization are fundamentally incompatible. That is, nobody yet knows for sure if a good raytracing CPU can be built on the same fundamental architecture as a good scanline rasterization CPU.


My gut feeling is that the two architectures are in fact incompatible, at least if one is genuinely interested in deploying raytracing hardware as a competitive replacement for scanline methods, and not merely a curiosity.

Quote:Original post by ApochPiQ
My gut feeling is that the two architectures are in fact incompatible, at least if one is genuinely interested in deploying raytracing hardware as a competitive replacement for scanline methods, and not merely a curiosity.

No they are not incompatible.
Take the first ray intersection test from the camera point of view as an example, compared to scanline rendering there is no difference, they both produce exactly the same result and the same data (just in different ways), but scanline does it a lot faster, even with the right RT hardware.
It is the same thing with stencil shadows where both methods produce the same result.

The difference comes first after the second ray intersection where raytracing can continue testing transparency without any real effort, but with scanline you either need to do some tedious sorting or use an advanced method like depth pealing, none of which works that well.
It's entirely possible to do the first pass with scanline and the rest with RT if needed, thus reducing the usage of RT

Quote:Original post by ApochPiQ
Geometry hit tests aren't a big deal

Yes they are, even though they are pretty fast in todays GPU programs, it's the shear number of intersect tests needed that call for heavy optimization.
A modern game today can have about 100000 polys in a single frame.
A 1080P screen has 2073600 pixels.
that means a relatively simple intersection test(let's say for shadows) needs 207360000000 ray-polygon intersection tests(that is without any optimization), or 207.36 billion tests per frame, and anything that is going to be run 200 billion times does matter.

Quote:Original post by lc_overlord
No they are not incompatible.
Take the first ray intersection test from the camera point of view as an example, compared to scanline rendering there is no difference, they both produce exactly the same result and the same data (just in different ways), but scanline does it a lot faster, even with the right RT hardware.
It is the same thing with stencil shadows where both methods produce the same result.

That's not what I'm talking about.

Like I noted several times, there are many well-known implementations of raytracing and even global illumination via raytracing on real GPUs, right now, today.

I'm not saying that raytracing can't be done on a GPU. I'm saying that the GPU memory architecture may not be the best arrangement for dedicated ray-tracing hardware. In other words, if you want to make a raytracing "card", the best way to do it is probably to invent a new design, not to base it on existing GPU architecture.

Quote:Original post by lc_overlord
The difference comes first after the second ray intersection where raytracing can continue testing transparency without any real effort, but with scanline you either need to do some tedious sorting or use an advanced method like depth pealing, none of which works that well.
It's entirely possible to do the first pass with scanline and the rest with RT if needed, thus reducing the usage of RT

And hybrid scanline/raytracing rendering is a waste of time if you're talking about dedicated hardware. Raytracing is predominantly interesting for visual phenomena beyond the first bounce; that is, raytracing is a powerful technique because of its recursive nature. In any real-world render, the number of recursive rays typically outnumbers first-hit rays; often times there are an order of magnitude more secondary rays than primary rays.

Eliminating the first hit is only a tiny speedup. If you want dedicated RT hardware, doing a hybrid of scanline and RT means you have to spend a lot of expensive chip space on the scanline support; it would be more efficient in many ways to just do pure RT and take the (negligible) performance hit. But that's a totally different rabbit-trail [smile]

Quote:Original post by lc_overlord

Quote:Original post by ApochPiQ
Geometry hit tests aren't a big deal

Yes they are, even though they are pretty fast in todays GPU programs, it's the shear number of intersect tests needed that call for heavy optimization.
A modern game today can have about 100000 polys in a single frame.
A 1080P screen has 2073600 pixels.
that means a relatively simple intersection test(let's say for shadows) needs 207360000000 ray-polygon intersection tests(that is without any optimization), or 207.36 billion tests per frame, and anything that is going to be run 200 billion times does matter.

Geometry hit tests are not the bottleneck. In theory, you can parallelize the hit tests without bound, until you're doing millions of hit tests simultaneously per ray.

In practice, however, this is not really possible, because it isn't possible with current memory bus designs to feed that much data into a chip. The challenge of RTRT in hardware is, as I said, not a matter of making ray-geometry tests fast. The challenge of RTRT in hardware is memory bandwidth.

Quote:Original post by ApochPiQ
The challenge of RTRT in hardware is memory bandwidth.

As with all other graphics hardware memory bandwidth is always the big limiter, current GPUs does have the same problem with texture sampling, i could use 50+ texture reads for each texture sample to get some nice filtering, but on current hardware i have to use a bad form of mipmaping with only 4-8 reads per sample.
The raytest grid processor is one way to reduce some of that bandwidth need as it doesn't need to transfer all that data for each test.

Quote:Original post by ApochPiQ
If you want dedicated RT hardware, doing a hybrid of scanline and RT means you have to spend a lot of expensive chip space on the scanline support

Sort of, but only if you use an older architecture.
The main portion in the common GPU is the programmable shader units, and you would still need those on a RTRT card, otherwise nothing will be rendered (in either of the two rendering methods), and because you now with SM4 have a unified shader architecture where the vertex, geometry and fragment processors run (or can run) on the same shader units.
So currently the only scanline rasterising specific circuitry is the actual rasteriser and that is not a big part of the chip (in theory this to could be run on a shader unit or two).
Anyway, once they figure out how to do a fast RTRT card, i do believe they will find a way to do scanline rasterasing at the same time, because that is what is needed to make these cards accepted, cheap and backwards compatible.