|
 |
In article <416d6075$1@news.povray.org>, "scott" <sco### [at] spam com>
wrote:
> Well, if you write a ray-object intersection algorithm that runs on the GPU,
> that would certainly help a lot. Of course POV-ray would need to be
> modified (and this will not likely happen, but it could be a patch, or
> another raytracer entirely). GPUs are *very* fast at doing the same code in
> parallel. So POV could give the GPU a batch of rays to calculate
> intersections with, the GPU can go away and do this and return the result
> when it's done. During this time the CPU can also be doing the same (and
> working out the pixels from the last GPU result). It would certainly speed
> things up, look at that link where they guy was getting 30fps from his
> simple raytracer and then was getting 1200fps when it was running with the
> GPU helping.
It's still not very useful to POV-Ray. It'd spend too much time copying
data to and from the card, and pulling data off the card is generally
not a fast operation...they're optimized for displaying triangles and
crunching numbers local to the card. What these demos are do is
basically hard code a simple, small raytracer and scene designed around
the abilities of the card into the pixel shader. It's fast because it
all fits on the card and it doesn't do anything that needs to move stuff
between the card and the main system. In addition, precision limitations
will be a huge problem...POV uses double precision for most
calculations, and it needs them. From what I've seen, GPUs use half
precision...good enough for a demo, but not enough for general
raytracing.
It's a neat trick, but it's just not general enough to handle what
POV-Ray needs to do. You might be able to make use of it with a more
limited raytracer (maybe a scientific visualization app, for example),
but it's of no help to POV-Ray.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
