Allen <nomail@nomail> wrote:
> Would it be possible to use the GPU as well as the CPU to render?

  The general answer is: No.

  There are currently two (non-exclusive) ways to use a GPU to speed up
rendering (or other calculations), neither of which is very useful in
raytracing (for reasons given below):

  A GPU can, quite obviously, be used for scanline-rendering triangles.
This is almost like raycasting, but not quite.
  Basically what the GPU does is to render one entire triangle at a time.
The Z-buffer is used for hidden surface removal. Unless the triangles are
rendered in a front-to-back order, there's quite a lot of wasted rendering.
(I'm sure, but it's possible that some games try to make the GPU render in
a front-to-back order, eg. by using a BSP tree, in order to make the
rendering faster, as it minimizes the amount of wasted rendered pixels.)

  The triangle-rendering capabilities of a GPU can sometimes be used for
something else than pure 3D graphics too (such as fast 2D blending, rotating,
and other similar effects), some of them quite ingenuous (I think some have
used the GPU triangle rendering for sound mixing...)
  One very typical usage of the triangle-rendering capability is to create
radiosity lightmaps.

  Another, more modern usage, is to make use of the mathematical
co-processors in current GPUs to perform other calculations. Especially
shaders can be used for much more than simply surface texturing. Some have
used them for quite a varied set of things, many not related with graphics
at all.

  Why doesn't either of these help in raytracing? Couldn't the triangle
rendering be used for the first recursion level of raytracing (iow. for
the raycasting step)? Couldn't shaders be used to raytrace?

  The answer is no, and the reason is that the data transmission overhead
between the GPU and the CPU is way too massive. A raytracer needs info
about objects, intersection points, etc. on a per ray basis. They shoot
a ray, and they need all info that ray provided right away, in order to
make a decision on what to do next (eg. for shooting a new reflected or
refracted ray from the intersection point). This means that for each ray
the raytracer will need to read data from the GPU, and this would be really
slow. It wouldn't help if the GPU is let to "raycast" the entire scene
first, and then all the data is read, because you are still reading the
data for every single pixel, and it doesn't make too much of a difference
in speed.

  Besides, the "raycasting" step, ie, the very first recusion level, is
not the slowest step in the whole raytracing process. On the contrary,
as far as I can see, it's usually the fastest and simplest. You can test
this by setting max_trace_level to 1 in POV-Ray. The scene will most
probably always render very fast, especially if it only consists of
triangle meshes (as it would have to, if you were going to use the GPU
to help in the raycasting process). The slowness of raytracing comes
from the subsequent recursion levels (as well as texturing, media, etc),
and the vast majority of time is spent there.

  Data transfer speed is also the reason why trying to use the math
co-processors in the GPU is not feasible. While they could in theory
perform some very fast operations, reading the results of those operations
is so slow that it would completely nullify the speed benefit.
  The only theoretical benefit from the GPU math co-processors could be
achieved if they could perform lengthy calculations with a small (in data
amount) result. For example, being able to fully raytrace a pixel would
probably be such a thing. However, I don't think GPUs will be able to
perform full raytracing anytime soon. Not with all the features in POV-Ray
(such as different types of primitives, procedural texturing, media, etc).
  (One big barrier to this is also that, AFAIK, shaders cannot be
recursive. They might not even support loops, if I remember correctly.)

-- 
                                                          - Warp

Post a reply to this message