![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3ee8ef8f$1@news.povray.org>,
"Ray Gardener" <ray### [at] daylongraphics com> 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] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ray Gardener <ray### [at] daylongraphics com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Ray Gardener
Subject: Re: Offloading some calculations to a GPU
Date: 13 Jun 2003 17:08:12
Message: <3eea3d3c@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3eea3d3c@news.povray.org>,
"Ray Gardener" <ray### [at] daylongraphics com> 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] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Ben Chambers
Subject: Re: Offloading some calculations to a GPU
Date: 14 Jun 2003 16:40:51
Message: <3eeb8853@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Michael Goldshteyn" <mgo### [at] n-o-s-p-a-m-earthlink net> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Ben Chambers
Subject: Re: Offloading some calculations to a GPU
Date: 14 Jun 2003 16:41:41
Message: <3eeb8885@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Rick [Kitty5]" <spa### [at] kitty5 com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Ben Chambers
Subject: Re: Offloading some calculations to a GPU
Date: 14 Jun 2003 16:45:19
Message: <3eeb895f@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Ray Gardener" <ray### [at] daylongraphics com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Ben Chambers
Subject: Re: Offloading some calculations to a GPU
Date: 14 Jun 2003 16:47:17
Message: <3eeb89d5@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Michael Goldshteyn" <mgo### [at] n-o-s-p-a-m-earthlink net> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |