I was wondering, while waiting for a render of course, how hard it would be to
get povray to use the 128 processors in my Nvidia card? My quad-core AMD
processor does a good job but there's always something bigger and more complex
to render.

Kevin

Post a reply to this message

"Random_Kevin" <nomail@nomail> wrote:
> I was wondering, while waiting for a render of course, how hard it would be to
> get povray to use the 128 processors in my Nvidia card? My quad-core AMD
> processor does a good job but there's always something bigger and more complex
> to render.

The answer to this type of question - which can be generalized as "can (or: why
can't, or: how hard would it be to make) POV-Ray use my graphics card?" -
hasn't changed since it was last asked a few months ago (no need to feel bad
about asking it though: it was about time again ;)):

GPUs are still (and can be expected to continue to be) unsuited to the general
task of ray tracing, and modifying POV-Ray to be able to dispatch part of its
computations to them would be cumbersome and probably ineffective.

The following quote from Wikipedia about the limitations of CUDA in particular
(but which also applies to GPUs in general) gives an insight why this is so:

"Threads should be running in groups of at least 32 for best performance, with
total number of threads numbering in the thousands. Branches in the program
code do not impact performance significantly, provided that each of 32 threads
takes the same execution path; the SIMD execution model becomes a significant
limitation for any inherently divergent task (e.g., traversing a ray tracing
acceleration data structure)."

GPUs are specialized on crunching a lot of numbers, all in exactly the very same
way. Raytracing does not provide many tasks that fit this bill; for each ray
there's a lot of decisions to make: Does this ray intersect object X? Is the
intersection point inside or outside of all the other objects in the same CSG
group? Has radiosity data been gathered in the vicinity? Is the object
reflective? Is it transparent? Does refraction occur? Does total reflection
occur? Does dispersion occur? And so forth.

There *may* be ways to implement raytracing in a manner that is suitable for GPU
operation, or at least "outsorcing" some tasks; but the POV-Ray code is
definitely not.

Post a reply to this message

clipka wrote:
> "Random_Kevin" <nomail@nomail> wrote:
>> I was wondering, while waiting for a render of course, how hard it would be to
>> get povray to use the 128 processors in my Nvidia card? My quad-core AMD
>> processor does a good job but there's always something bigger and more complex
>> to render.
> 
> The answer to this type of question - which can be generalized as "can (or: why
> can't, or: how hard would it be to make) POV-Ray use my graphics card?" -
> hasn't changed since it was last asked a few months ago (no need to feel bad
> about asking it though: it was about time again ;)):
> 
> GPUs are still (and can be expected to continue to be) unsuited to the general
> task of ray tracing, and modifying POV-Ray to be able to dispatch part of its
> computations to them would be cumbersome and probably ineffective.
> 
> The following quote from Wikipedia about the limitations of CUDA in particular
> (but which also applies to GPUs in general) gives an insight why this is so:
> 
> "Threads should be running in groups of at least 32 for best performance, with
> total number of threads numbering in the thousands. Branches in the program
> code do not impact performance significantly, provided that each of 32 threads
> takes the same execution path; the SIMD execution model becomes a significant
> limitation for any inherently divergent task (e.g., traversing a ray tracing
> acceleration data structure)."
> 
> GPUs are specialized on crunching a lot of numbers, all in exactly the very same
> way. Raytracing does not provide many tasks that fit this bill; for each ray
> there's a lot of decisions to make: Does this ray intersect object X? Is the
> intersection point inside or outside of all the other objects in the same CSG
> group? Has radiosity data been gathered in the vicinity? Is the object
> reflective? Is it transparent? Does refraction occur? Does total reflection
> occur? Does dispersion occur? And so forth.
> 
> There *may* be ways to implement raytracing in a manner that is suitable for GPU
> operation, or at least "outsorcing" some tasks; but the POV-Ray code is
> definitely not.
> 
> 
> 
You are talking about the vertex shader part of a graphics card and its 
limited applicability to surfaces generated mathematically via POV-Ray. 
  I am more interested in the pixel shader and offloading the texture 
evaluation, especially the built-in patterns, to the graphics card. 
That should be much easier.

Post a reply to this message

David Wallace wrote:
> You are talking about the vertex shader part of a graphics card and its 
> limited applicability to surfaces generated mathematically via POV-Ray. 
>  I am more interested in the pixel shader and offloading the texture 
> evaluation, especially the built-in patterns, to the graphics card. That 
> should be much easier.

Of course, and much less effective, too ;-)  Before you embark on optimizing 
a ray-tracer, you need to understand where performance bottlenecks exist 
(see literature) ... and for ray-tracing that very, very rarely is the 
texturing code.

	Thorsten

Post a reply to this message

David Wallace wrote:

> You are talking about the vertex shader part of a graphics card and its 
> limited applicability to surfaces generated mathematically via POV-Ray. 
>  I am more interested in the pixel shader and offloading the texture 
> evaluation, especially the built-in patterns, to the graphics card. That 
> should be much easier.

With Cuda you no longer need to think in terms of vertex shader
or pixel shader. You still need to think in the terms of computing
architecture, i.e., massive parallelization with extremely limited
local memory and highly expensive access to global data structures.
Also, an individual calculation must be expensive enough to warrant
the overhead of delegating its execution to the GPU.

That being said, if someone is looking for a pet Cuda project,
I think media would be a hot candidate to benefit from the GPU
(without radiosity & photon interaction, though). It would be
possible to parallelize over the sample count, and relevant
data should fit within the 16KB of a processor cluster
(mainly light sources and density functions?).

Post a reply to this message

David Wallace <Dav### [at] comcastnet> wrote:
>   I am more interested in the pixel shader and offloading the texture
> evaluation, especially the built-in patterns, to the graphics card.
> That should be much easier.

I don't think this would really give any advantage either, unless you have a
bunch of texels to work on simultaneously - which POV-Ray's architecture is
highly unsuited for.

Post a reply to this message