In article <3ee74af9$2@news.povray.org>,
 "Michael Goldshteyn" <mgo### [at] n-o-s-p-a-m-earthlinknet> wrote:

> Most modern PCs have a very powerful 3d video card with a GPU that is
> hundreds if not thousands of times faster than the CPU for certain
> calculations. I was thinking if some of the POV computations could be
> offloaded to the GPU, we could speed up renders by a very large factor. The
> big question is one of which routines thouse would be and which chunks of
> the GPU could be utilized. Certainly matrix operations could be offloaded at
> the very least, although I don't know to what extent that would improve
> performance. It's just a shame that there is this uber-powerful floating
> point processor sitting in most PCs that can't be used to help things move
> along. What do others think?

As others have mentioned, because of precision issues, this isn't useful 
for geometry calculations. But more importantly, this isn't like a 
floating point coprocessor, it is a video card, and is designed to 
efficiently display things. Even if the card can do the operations 
faster, it will take far more time to send the data to the card to be 
processed and then retrieve it than it would to process the data on the 
CPU. There are some things it could accelerate, but typically not what 
POV needs.
With more programmable cards becoming available, you can do more 
general-purpose things with the card...it may be possible to process 
data in large enough chunks that it is worth it to use the card, maybe 
even doing all the raytracing on the card. However, you'd most likely 
have to design the raytracer around this, I don't see anyone converting 
POV to do it. And then you have the hardware dependencies, etc...

-- 
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

> You need double precision floating-point processing.  Sorry!
>
>     Thorsten


What if... we limited the scene extents (in a seperate
version of POV-Ray, of course) to some small volume
like 1024 cubic units where single-precision floats
would be more viable? One could only render small scenes
or single objects, but when developing single objects
(like people or cars), that's acceptable.

The Tachyon raytracer
http://jedi.ks.uiuc.edu/~johns/raytracer/
has an option to build using
single precision (I imagine typedef'ing POV's DBL type
to float instead of double would be analogous), and
its author reports a 5-20% speed increase even without
hardware leveraging. He had to customize his epsilon
constants but I think it shows that using single precision
is possible. If I was modeling a chair or whatever,
I wouldn't turn down any speed improvement, even if
the occasional triangle had a gap.

POV's bounding slab bbox are already single-precision,
interestingly. BBOX_VAL is type SNGL.


Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com

Post a reply to this message

In article <3ee8ef8f$1@news.povray.org>,
 "Ray Gardener" <ray### [at] daylongraphicscom> wrote:

> What if... we limited the scene extents (in a seperate
> version of POV-Ray, of course) to some small volume
> like 1024 cubic units where single-precision floats
> would be more viable? One could only render small scenes
> or single objects, but when developing single objects
> (like people or cars), that's acceptable.

1024 units would probably still be a bit large. This has been done 
before, and is actually slower on modern systems (there was a thread 
about it recently on comp.graphics.rendering.raytracing). You go through 
a lot of contortions to get it to work, and get a more limited, lower 
quality, slower renderer as a result. Now do you see why?


> The Tachyon raytracer
> http://jedi.ks.uiuc.edu/~johns/raytracer/
> has an option to build using
> single precision (I imagine typedef'ing POV's DBL type
> to float instead of double would be analogous), and
> its author reports a 5-20% speed increase even without
> hardware leveraging. He had to customize his epsilon
> constants but I think it shows that using single precision
> is possible. If I was modeling a chair or whatever,
> I wouldn't turn down any speed improvement, even if
> the occasional triangle had a gap.

> POV's bounding slab bbox are already single-precision,
> interestingly. BBOX_VAL is type SNGL.

Yes, so are mesh vertices. In the former case, precision errors are 
relatively unimportant. In the second case, it is a matter of practical 
storage of large meshes, made possible by the fact that the intersection 
calculations don't stress the precision much. There are other objects 
that strain the limits of double precision, Tachyon only has spheres, 
infinite planes, triangles, rings, cylinders, boxes, a kind of 
internally generated fractal height field which is tessellated to a 
mesh, quadrics, voxels. Probably the most precision-requiring one is the 
generic quadric, a second-order surface. POV supports generic cubics 
(third order), toruses and generic quartics (which are fourth-order), 
and generic polynomial shapes up to 7th order. Also, blobs, julia 
fractals, lathe/sor, prism, sphere sweeps, superellipsoids...you get the 
idea.

-- 
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

Ray Gardener <ray### [at] daylongraphicscom> wrote:
>> You need double precision floating-point processing.  Sorry!

> What if... we limited the scene extents (in a seperate
> version of POV-Ray, of course) to some small volume
> like 1024 cubic units where single-precision floats
> would be more viable?

  I think that you misunderstand how floating point arithmetic works.
It's not about the maximum value. It's about precision.
  Granted, single-precision floating point numbers have a smaller upper
limit than double-precision. However, this upper limit is at about 3.4*10^38
(that is, 340000000000000000000000000000000000000), which is certainly
much larger than that 1024.

> POV's bounding slab bbox are already single-precision,
> interestingly. BBOX_VAL is type SNGL.

  That's because a bounding box does not need that much *accuracy*.
The maximum value of single precision is plenty for bounding boxes.
Which demonstrates well the whole point. Actual objects can often need
the extra accuracy in order to render properly.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

> This has been done
> before, and is actually slower on modern systems (there was a thread
> about it recently on comp.graphics.rendering.raytracing). You go through
> a lot of contortions to get it to work, and get a more limited, lower
> quality, slower renderer as a result. Now do you see why?

Hmmm...

To be sure, I downloaded Tachyon and built
double- and single-precision DOS versions and put
them to the test. The results (in seconds,
on a 633 Mhz Celeron):

island (an hf with reflecting water):
  44.131 DP vs. 32.903 SP

teapot (specular material with reflecting plane):
  12.898 DP vs. 9.993 SP

820spheres (a flat but shadowed sphereflake):
  18.135 DP vs. 13.971 SP


I also checked the images to test quality, but found
no discernable difference. No gaps, nothing.

Perhaps the raw computation time for double precision
is as good as or better than single precision, but
the memory latency is lower since half as much
numeric data is being referenced. Well, whatever it
is, there's a difference in favor of SP. I'm going
to try it later today on a modern box which has
a much faster memory bus as well, just to be sure.

As for the primitives, yeah, Tachyon doesn't
have the complex ones, but if it has enough,
and one can get SIMD or GPU assist in the bargain,
then that's not a bad little raytracer for some projects.
I wouldn't mind having a "turbo option" for simple
scenes in POV-Ray.

Ray

Post a reply to this message

In article <3eea3d3c@news.povray.org>,
 "Ray Gardener" <ray### [at] daylongraphicscom> wrote:

> > This has been done
> > before, and is actually slower on modern systems (there was a thread
> > about it recently on comp.graphics.rendering.raytracing). You go through
> > a lot of contortions to get it to work, and get a more limited, lower
> > quality, slower renderer as a result. Now do you see why?

Crap...thought I was replying to something else, and was thinking of 
64-bit fixed-point here. Single-precision floating point isn't slower, 
and even when the instructions execute in the same time, they take less 
cache and RAM space.


> I also checked the images to test quality, but found
> no discernable difference. No gaps, nothing.

Well, the scenes you tried only used planes, triangles, and spheres, 
which aren't very precision sensitive. I think you'd have a lot harder 
time with something like a torus, and a more complex, "real-world" scene.


> As for the primitives, yeah, Tachyon doesn't
> have the complex ones, but if it has enough,
> and one can get SIMD or GPU assist in the bargain,
> then that's not a bad little raytracer for some projects.
> I wouldn't mind having a "turbo option" for simple
> scenes in POV-Ray.

This would be extremely unlikely to happen...it would create a lot more 
maintenance work. Many things would have to be separately tuned, 
rewritten, or completely disabled for the single-precision version.

-- 
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

"Michael Goldshteyn" <mgo### [at] n-o-s-p-a-m-earthlinknet> wrote in
message news:3ee7510b$1@news.povray.org...
> After doing more reading, the 128 bit precision may refer to 32-bit
floating
> point times four. So, in fact, the GPU may only be single-precision per
> color.

Actually, the color on an FX5900 should be able to be set to 128bit instead
of 32bit (ie, 32bits per channel, as opposed to the typical 8).  However,
the vertex operations (ie, matrix transforms) are still single precision.

...Chambers

Post a reply to this message

"Rick [Kitty5]" <spa### [at] kitty5com> wrote in message
news:3ee77604$1@news.povray.org...
> Thorsten Froehlich wrote:
> > You need double precision floating-point processing.  Sorry!
>
> But do you *really* need it for everything

No, just vertices.  Attempts have been made in the past using single
precision, and it's just not enough for raytracing.

...Chambers

Post a reply to this message

"Ray Gardener" <ray### [at] daylongraphicscom> wrote in message
news:3ee8ef8f$1@news.povray.org...
> > You need double precision floating-point processing.  Sorry!
> >
> >     Thorsten
>
>
> What if... we limited the scene extents (in a seperate
> version of POV-Ray, of course) to some small volume
> like 1024 cubic units where single-precision floats
> would be more viable? One could only render small scenes
> or single objects, but when developing single objects
> (like people or cars), that's acceptable.

You seem to think the size of the scene matters.  This is the reason we use
*floating* point - the actual size doesn't matter, just the difference
between the largest and smallest objects.

Ie, two spheres that are 10,000,000 units across will render just as
accurately as two spheres that are 1 unit across.  However, if you put a
third sphere that's one unit across between the two spheres, then you'll
need the extra precision.

...Chambers

Post a reply to this message

"Michael Goldshteyn" <mgo### [at] n-o-s-p-a-m-earthlinknet> wrote in
message news:3ee74af9$2@news.povray.org...
> Most modern PCs have a very powerful 3d video card with a GPU that is
> hundreds if not thousands of times faster than the CPU for certain
> calculations. I was thinking if some of the POV computations could be
> offloaded to the GPU, we could speed up renders by a very large factor.
The
> big question is one of which routines thouse would be and which chunks of
> the GPU could be utilized. Certainly matrix operations could be offloaded
at
> the very least, although I don't know to what extent that would improve
> performance. It's just a shame that there is this uber-powerful floating
> point processor sitting in most PCs that can't be used to help things move
> along. What do others think?

The GPU itself is designed for a different pipeline.  It's not like a
coprocessor; that is, you can't just send vertices to it and get the
transformed vertices back.  You *can* process the vertices on the card, and
then have the card draw them.

...Chambers

Post a reply to this message