I was curious, with the OpenCL 1.0 spec, and also with ATI/AMD releasing
open-source code now for utilizing the GPU processing power, could it be
possible to utilize GPU acceleration within POV-Ray?  I know a lot of POV-Ray
is CPU intensive and utilizing the threads in the GPU would drastically speed
up render times.

anyones thoughts?

Post a reply to this message

Doom wrote:
> I was curious, with the OpenCL 1.0 spec, and also with ATI/AMD releasing
> open-source code now for utilizing the GPU processing power, could it be
> possible to utilize GPU acceleration within POV-Ray?  I know a lot of POV-Ray
> is CPU intensive and utilizing the threads in the GPU would drastically speed
> up render times.
> 
> anyones thoughts?
> 

This comes up about once a month. The practical answer is, "No, not 
really, since GPUs are optimized for the type of math that is used by 
scanline systems, not physics based raytracing, and their floating point 
systems are almost always using lower bit depth than the CPU of the same 
machine, so nearly everything POVRay does would fall in the category of, 
"Nope, the GPU can't do that, or if it did, it would produce results 
that are poorer than the FPU of the main processor."

Now, if you didn't mind getting "poorer" quality, and the *slight* speed 
increase you might get from it was worth it... maybe. But, unless its 
enough to give you real time, its not worth the effort, since the only 
reason you might want to downgrade the results, to get better 
performance, is as a game engine. And actually, I kind of wish you could 
do that. I am getting seriously tired of things like the layers alpha BS 
in Second Life, which a raytracer would never have in the first place. lol

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

"Doom" <mar### [at] gmailcom> wrote:
> I was curious, with the OpenCL 1.0 spec, and also with ATI/AMD releasing
> open-source code now for utilizing the GPU processing power, could it be
> possible to utilize GPU acceleration within POV-Ray?  I know a lot of POV-Ray
> is CPU intensive and utilizing the threads in the GPU would drastically speed
> up render times.

There has already been some mention in the FAQ.

The first question will be: Does OpenCL support double-precision floats? If not,
then forget it, because that's the precision POV needs. I wouldn't be surprised
if games could do fine with single-precision.

The next question would be: How to distribute the workload? Just running another
POV render thread in the GPU will hardly work.

I guess it wouldn't be worth the pain. With SSE2, the compiler will help you to
make some use of it. With OpenCL, the compiler probably cannot, so a lot of
manual changes to the code would be needed, and designing them for portability
(so that the program can still run on non-OpenCL systems) could be quite a
problem.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Doom" <mar### [at] gmailcom> wrote:
> > I was curious, with the OpenCL 1.0 spec, and also with ATI/AMD releasing
> > open-source code now for utilizing the GPU processing power, could it be
> > possible to utilize GPU acceleration within POV-Ray?  I know a lot of POV-Ray
> > is CPU intensive and utilizing the threads in the GPU would drastically speed
> > up render times.
>
> There has already been some mention in the FAQ.
>
> The first question will be: Does OpenCL support double-precision floats? If not,
> then forget it, because that's the precision POV needs. I wouldn't be surprised
> if games could do fine with single-precision.
>
> The next question would be: How to distribute the workload? Just running another
> POV render thread in the GPU will hardly work.
>
> I guess it wouldn't be worth the pain. With SSE2, the compiler will help you to
> make some use of it. With OpenCL, the compiler probably cannot, so a lot of
> manual changes to the code would be needed, and designing them for portability
> (so that the program can still run on non-OpenCL systems) could be quite a
> problem.


Thank you for the input.  All of it makes sense.  From my knowledge, most
current GPU's do support double precision floats, however, not nearly at the
speed as single precision, as there isn't the need in graphics today.

I know some cards to exist that are designed more for math / calcuations and not
graphics, but i do not know much about those workstation cards, and/or what all
they do support.

Thanks again for the quick input!  It answered my curiosity of the day.

-Mark

Post a reply to this message

Patrick Elliott wrote:
> This comes up about once a month. The practical answer is, "No, not
> really, since GPUs are optimized for the type of math that is used by
> scanline systems, not physics based raytracing, and their floating point
> systems are almost always using lower bit depth than the CPU of the same
> machine, so nearly everything POVRay does would fall in the category of,
> "Nope, the GPU can't do that, or if it did, it would produce results
> that are poorer than the FPU of the main processor."

Modern GPUs are very programmable; they aren't tied to scanline rendering
anymore. Ever heard of protein folding on GPUs?

Raytracing *can* be done in GPUs.
See http://www.clockworkcoders.com/oglsl/rt/

However it would be a HUGE amount of work to modify POV-Ray to run on CUDA /
OpenCL. Lots of algorithms would need to be rewritten from scratch, and a
few may be impossible.

Post a reply to this message

This is a very interesting summary for one such "GPU raytracer" project:

http://www.ce.chalmers.se/edu/proj/raygpu/index.php?view=projects

In particular:
"So far we have not been able to acquire rendering times that compete with
established ray tracers like mental ray but then again this has never been the
objective of this thesis. Writing fast ray tracers with the help of graphics
hardware is something that we believe is definitely possible though. A good
idea is probably to use the graphics card only for some parts of the rendering
like for example intersection tests and shading and letting the CPU take care
of the traversal of data structures and such."

I thought running it through a GPU would automatically yield even a naive
raytracer an immense boost in performance.  But then, not even MentalRay nor
VRay seem much interested in running on GPU either.

Post a reply to this message

(Sorry it took me so long to respond, our internet connection was down
for a while).

While the OpenCL spec is very exciting for the GPGPU effort, it will not
help renderers such as POV-Ray.  Ultimately, they still come down to a
SIMD design: specify one instruction (or one set of instructions), and
run it on multiple sets of data.

In practice, this means that anything with a high degree of branching
(ie POV-Ray) won't benefit nearly as much.

Of course, the new GPUs are more capable than ever, and they do offer
double precision floating point, so it may at one point be possible for
limited aspects of the renderer.  However, bear in mind that even
something as inherently SIMD as video encoding, using a high end GPU
from NVidia (the GeForce 260) was actually *slower* than a stock Core 2
Duo from Intel (1).  Something with as much branching as POV-Ray will
perform even worse.

So, there's new hope for the future, but it's still a *distant* future.

(1)
http://xtreview.com/addcomment-id-6872-view-CUDA-video-performance-using
-TMPGEnc-4.0-Xpress.html

...Ben Chambers
www.pacificwebguy.com

The plural of anecdote is not data  --Elbows

Post a reply to this message

For what I have read about it, GPUs are great for geometry and some 
other graphic related calculations, because they have more sophisticated 
  hardwired, say trigonometric, functions that the FPU simply doesn't 
have, this leads me to ask the experienced programmers here if how huge 
would be to make a rough "previewer", real-time if possibile, for 
POV-Ray? Correct me if I'm wrong but at some point that effort has to be 
easy because the GPU have this scene elements analog to POV-Ray's 
(lightning, primitives, colors, phong, diffuse, etc.), why is so hard to 
use resemblance in features to POV-Ray's favor? I know... is only 32-bit 
precision, is not 100% compatible, POV-Rays is Hyper-complex and 
wealthy-rich in features but, somehow can't the to GPU along with the 
FPU & CPU can't get to cut a deal that can give u an estimate of what 
you'll receive if the scene is rendered?

  I really whish I could answer this myself...maybe a como of GPU 
features can give some of the most complex POV-Ray's features? maybe a 
rough rough preview, something that can "guess"(fast calculations with 
GPU+FPU+CPU) to get just an estimation of the final colors and effects 
on the objects, and mainly this could be used to preview the modeled 
geometry of solids and surfaces and the lighting on the scene, rather 
than actually have a correct colored accurate scene, don't you think?

Another suggestion, what about this:
a small floating window (maybe 512*384 or 384*288) with the title "rough 
preview" that makes the GPU+FPU+CPU preview of the scene as ral-time as 
possible "while you type" or when you have finished a valid line, this 
could be configurable, but I think would be great as a default.

This ideas is so incompatible with reality? I hope not, you tell me :)

Regards.

Post a reply to this message

In the spirit of co-processing (GPU+FPU+CPU) I would like to suggest 
that if isn't too much of a trouble, would be great if POV-Ray could 
have a GPU+CPU(CPU included) Identifier (GPU-Z, CPU-Z,etc) to use 
available processing hardware resources to render, *of course* GPU 
helping whenever it can keep with POV-Ray's quality specs and/or "rough 
preview". Makes sense?

Post a reply to this message

Saul Luizaga <sau### [at] netscapenet> wrote:
(<GPU preview>)

Interesting idea. Would be a lot of work to implement though, I guess.

> Another suggestion, what about this:
> a small floating window (maybe 512*384 or 384*288) with the title "rough
> preview" that makes the GPU+FPU+CPU preview of the scene as ral-time as
> possible "while you type" or when you have finished a valid line, this
> could be configurable, but I think would be great as a default.

Great idea, but what if your scene file takes 15 minutes to (re-)parse because
of heavy macro usage? And what if you are working on SDL code designed to write
to files (radiosity samples, photons, or just plain #write output)? I wouldn't
want POV to just start running *such* SDL code while it isn't "ready to rock"
yet.

(Or what if all the changes you want to do is just a few #defines that govern
whether your SDL file *does* #write or instead #read some stuff, in order to
switch from #write to #read mode... don't even want to think about it. Argh!)

No, I think the idea is intriguing, but prohibitive due to the power of POV's
SDL language.

Post a reply to this message

Saul Luizaga <sau### [at] netscapenet> wrote:
> In the spirit of co-processing (GPU+FPU+CPU) I would like to suggest
> that if isn't too much of a trouble, would be great if POV-Ray could
> have a GPU+CPU(CPU included) Identifier (GPU-Z, CPU-Z,etc) to use
> available processing hardware resources to render, *of course* GPU
> helping whenever it can keep with POV-Ray's quality specs and/or "rough
> preview". Makes sense?

If we're talking about using GPU to support regular render, then I guess this is
a no-go: Modifying POV to this effect *would* be too much of a trouble, that's a
definite.

It might be possible to add a dedicated "preview module" though, which could
then make use of different GPU hardware... anyone volunteer for this task?

(Just as a side note, I don't have much hope that there will actually be too
many people screaming "me!" right now; I also think that at the time being,
development effort is better invested in other areas.)

Post a reply to this message

I see what you mean and yes, there will be times where such preview 
window could not be displayed and would be great to have a way to 
indicate to the window that ignore certain if not all the code, 
activating or deactivating the window with a hot-key and another hot-key 
  for the preview.

As I say the preview would be only for certain aspects of POV-Ray that 
can be quickly if not real-time previewed, of course if the parsing 
would take time "preview as you type" would be a no-go.

I propose this humble solution: have the preview Window to open a copy 
of the source code window but not for editing but for selecting the 
parts of the code that will be preview IF they don't take too long to 
parse, with an easy paragraph/structure selection with small bookmarks 
of paragraphs/structure "bookmarks" like Acrobat Reader displays when a 
.pdf has bookmarks. Also would be good that the preview starts when you 
open you .pov (if configured this way), and to make open-up preview, the 
would simply add elements to that preview as you create them and select 
them for preview, eliminating the need to re-preview the scene.

Regards.

Post a reply to this message

The problem is that GPUs, in their current form, are great for 
processing triangles but not much else.

POV-Ray, on the other hand, uses a wide variety of geometric primitives.

There *was* a version floating around that did a tessellated preview 
using OpenGL.  While functional, it never really caught on (AFAIK, the 
prevailing method of a quick preview is to #declare several identifiers 
specifying quality levels at the head of your main .pov file).

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers wrote:
> The problem is that GPUs, in their current form, are great for 
> processing triangles but not much else.

I have to desagree, Ihave seen examples on some web pages how the GPU 
beat the crap out of a CPU (FPU included) on certain calculations, I was 
reading about "GPUs as a powerful co-processor" or something like that. 
Those calculations were prety complex for 3D geometry solving and other 
stuff I don't recall well, was like a year or so ago.

As someone mentioned there is a version of Human Proteome Folding - 
Phase 2 for GPU processing, alsmost none CPU/FPU usage.


> POV-Ray, on the other hand, uses a wide variety of geometric primitives.

The preview would be as i wrote on another post on this thread a rough 
rough "preview" and not a mini/fast rendering,  if not all POV-Ray 
features can be "previewed" then only what it can, *and* a on the status 
mini-window saying what was previewed and what not, in short, I think 
the preview has to be a "glance window".

> There *was* a version floating around that did a tessellated preview 
> using OpenGL.  While functional, it never really caught on (AFAIK, the 
> prevailing method of a quick preview is to #declare several identifiers 
> specifying quality levels at the head of your main .pov file).
> 

A begining...

Post a reply to this message

Saul Luizaga <sau### [at] netscapenet> wrote:
> Chambers wrote:
> > The problem is that GPUs, in their current form, are great for 
> > processing triangles but not much else.

> I have to desagree, Ihave seen examples on some web pages how the GPU 
> beat the crap out of a CPU (FPU included) on certain calculations, I was 
> reading about "GPUs as a powerful co-processor" or something like that. 
> Those calculations were prety complex for 3D geometry solving and other 
> stuff I don't recall well, was like a year or so ago.

  The GPU can only be used to your advantage if you can give it a big
bunch of calculations to perform, let it crunch the numbers for several
seconds (or minutes) and then retrieve the results.

  However, generally speaking, a raytracer like POV-Ray cannot do that.
You could delegate some calculations to the GPU, but the amount of
calculations the GPU could do before the results would have to be retrieved
by POV-Ray would be way too small. Transferring data between the CPU and
the GPU has so much overhead that it overwhelms any advantage the GPU might
have over the CPU if the data has to be transferred continuously.

  If you could put the entire scene into the GPU and implement eg. the
ray-object intersection routines completely on GPU, that would be of
great help in the raytracing process (because POV-Ray could make the GPU
calculate a whole bunch of intersections at a time and then retrieve them
all in one single data burst). However, you would have to basically
replicate most of the POV-Ray code code as GPU code, with support for
all possible primitives and optimizations (such as bounding box hierarchies),
and that's just not possible.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> However, you would have to basically
> replicate most of the POV-Ray code code as GPU code, with support for
> all possible primitives and optimizations (such as bounding box hierarchies),
> and that's just not possible.

Well, let's be wise and say "not feasible" instead... I'm always reluctant to
call something impossible unless it's plain proven fact.

Post a reply to this message

Saul Luizaga <sau### [at] netscapenet> wrote:
> I have to desagree, Ihave seen examples on some web pages how the GPU
> beat the crap out of a CPU (FPU included) on certain calculations, I was
> reading about "GPUs as a powerful co-processor" or something like that.
> Those calculations were prety complex for 3D geometry solving and other
> stuff I don't recall well, was like a year or so ago.

Unfortunately, the keywords here are "CERTAIN calculations", and "CO-processor"

Or, to put it another way: There is *some* reason why we're not yet running
computers with GPUs *instead* of CPUs.

GPUs excel in specialized bulk data processing (they can be reprogrammed to
change their specialization nowadays, but that still doesn't invalidate this
statement), while CPUs provide for more flexibility.

I could imagine an approach to write a raytracing engine that could quite easily
"outsource" bulk data to a GPU; however, POV does *not* use this approach, and
can't be made to without a virtually complete rewrite.

I think I'm repeating myself, but anyway: Your proposal seems a nice idea, yet
probably has a too low benefit/effort ratio for the average POV user to place
it anywhere high on the development agenda.

Post a reply to this message

>  The GPU can only be used to your advantage if you can give it a big
> bunch of calculations to perform, let it crunch the numbers for several
> seconds (or minutes) and then retrieve the results.

The main problem for raytracing is that GPUs don't handle recursion very 
well, GPUs work by running set code on a group of data points, you cannot 
arbitrarily create new data points or even write to several different data 
points in your code.

All GPU code must essentially be structured like this:

For every element I of an array A:
- Read some elements a,b,c,... from other arrays (not array A)
- Do some processing based on a,b,c,...
- Write a single result to element I

As you can see it is totally geared for calculating pixel colours for your 
screen from texture arrays and bump maps etc.

Of course you can chain together blocks like that to do more complicated 
things in clever ways, but a complete raytracer does not fit in to that 
scheme at all really.

Post a reply to this message

Thank you to all that replied me, I have read all the posts and yes, I 
think my idea has little to no use, and would take some sort of 
translation from POV-Ray parsing and some minimum raytracing to put a 3D 
"preview" in an universal OpenGL format (previous GPU caps diag) to send 
it to the GPU and display it, or some sort of .pov analyzer to create 
such image or something like that. Interesting challenge, I wish I could 
start it.

Thank you all again, you have enlighten me.
Cheers.

Post a reply to this message

Saul Luizaga wrote:
>  this leads me to ask the experienced programmers here if how huge
> would be to make a rough "previewer", real-time if possibile, for
> POV-Ray? 

http://www.daylongraphics.com/other/povray/patches/

http://www.kfunigraz.ac.at/imawww/thaller/wolfgang/vop-intro.html

and there might be others

Post a reply to this message

Hi,
Iam a newbee. A colleague asked me to do some research in using pov-ray and GPU.
After reading your comments it seems not a good idea to render pictures with GPU
power because of single precision. But what about the Nvidia Tesla and its high
DP processing power? Are there any project in progress or does it make sense to
think about using the Nvidia Tesla GPUs for rendering?

greetings
SEb

Post a reply to this message

Am 14.12.2010 08:53, schrieb oleg:
> Hi,
> Iam a newbee. A colleague asked me to do some research in using pov-ray and GPU.
> After reading your comments it seems not a good idea to render pictures with GPU
> power because of single precision. But what about the Nvidia Tesla and its high
> DP processing power? Are there any project in progress or does it make sense to
> think about using the Nvidia Tesla GPUs for rendering?

Those comments are outdated, as double precision does not seem a problem 
anymore on modern GPUs (at least the high-end ones, and GP-GPUs such as 
Tesla).

Fusing POV-Ray with GPU would be a challenging task, as POV-Ray's 
internal architecture relies on recursive function calls, which are 
still a problem with GPUs; also, POV-Ray does not provide any 
sophisticated mechanisms to "bundle" rays into batches to undergo 
simultaneous processing (which would be necessary to exploit the full 
power of a GPU); you would need some mechanism to identify "similar" 
rays ("coherence" would be a buzzword here, though not in the laser sense).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Fusing POV-Ray with GPU would be a challenging task, as POV-Ray's
> internal architecture relies on recursive function calls, which are
> still a problem with GPUs; also, POV-Ray does not provide any
> sophisticated mechanisms to "bundle" rays into batches to undergo
> simultaneous processing (which would be necessary to exploit the full
> power of a GPU); you would need some mechanism to identify "similar"
> rays ("coherence" would be a buzzword here, though not in the laser sense).

Luxrays is a GPL providing precisely such mechanism:

http://www.luxrender.net/wiki/index.php?title=LuxRays

Post a reply to this message

Am 14.12.2010 16:47, schrieb nemesis:

> Luxrays is a GPL providing precisely such mechanism:
>
> http://www.luxrender.net/wiki/index.php?title=LuxRays

Quote from the features list:

triangle mesh primitive support (support for other kind of primitive may 
be added in the future);

That currently makes it an absolute no-go for POV-Ray.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 14.12.2010 16:47, schrieb nemesis:
>
> > Luxrays is a GPL providing precisely such mechanism:
> >
> > http://www.luxrender.net/wiki/index.php?title=LuxRays
>
> Quote from the features list:
>
> triangle mesh primitive support (support for other kind of primitive may
> be added in the future);
>
> That currently makes it an absolute no-go for POV-Ray.

more like a 1-go.

Post a reply to this message

Am 14.12.2010 18:49, schrieb nemesis:

>> triangle mesh primitive support (support for other kind of primitive may
>> be added in the future);
>>
>> That currently makes it an absolute no-go for POV-Ray.
>
> more like a 1-go.

no, a 0-go. POV-Ray is too generic when it comes to objects. It doesn't 
really make much sense to make an exception specifically for meshes.

Post a reply to this message