I have just learned about it and I think this could be a great 
improvement for POV-ray since uses: CPUs, GPUs and "any other 
processors" to process programs. I'll clarify even more just in case: 
OpenCL lets you use CPU(s) Core(s) + GPU(s) Core(s) + "Any other 
processor(s)/core(s)"; but for most of us is just: CPU(s) Core(s) + 
GPU(s) Core(s).

PS: I think it should be a 'Suggestions' newsgroup for this sort of things.

Post a reply to this message

Saul Luizaga schrieb:
> I have just learned about it and I think this could be a great 
> improvement for POV-ray since uses: CPUs, GPUs and "any other 
> processors" to process programs. I'll clarify even more just in case: 
> OpenCL lets you use CPU(s) Core(s) + GPU(s) Core(s) + "Any other 
> processor(s)/core(s)"; but for most of us is just: CPU(s) Core(s) + 
> GPU(s) Core(s).

(*groans*)

Sorry, but you violated the "suggetions to use GPU to speed up POV-Ray 
may (and invariably will) be posted in intervals of 3 months" rule... we 
just had this discussion about CUDA.

OpenCL can't change the basic hardware architecture of a GPU; all it 
does is provide a layer on top (= added overhead!) to faciliate porting 
existing programs to GPUs - still those programs must be suited to the 
GPU architecture in order for the added processing power to outweigh the 
surplus inter-xPU communication overhead, let alone give any speed benefit.

As soon as POV-Ray is fully capable of running a distributed render on a 
network, it *might* be worth investigating whether the render back-end 
could also be fully ported to GPUs, to just add some more "machines" to 
the team. Until then, I don't think it makes much sense to think about 
it (unless we'd want to develop a completely new render engine using a 
totally different approach). And even then, question is whether the GPU 
would be fast enough at the tasks at hand to pay off the effort of 
getting the code to compile for the GPU.

OpenCL, however, will definitely *not* be an option, as it is a subset 
of C (the 3.7 code is written in C++), and has severe limitations that 
POV-Ray's architecture cannot comply with - most notably that recursions 
are not allowed. POV-Ray absolutely positively needs recursions to 
handle secondary rays, and also uses recursive calls for nested 
definitions of textures pigments or CSG objects.


> PS: I think it should be a 'Suggestions' newsgroup for this sort of things.

povray.pov4.discussion.general might be an appropriate spot.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> (*groans*)

I think the standard answer should just be "Go right ahead!  Come back when
you're done."

 - Ricky

Post a reply to this message

triple_r schrieb:
>> (*groans*)
> 
> I think the standard answer should just be "Go right ahead!  Come back when
> you're done."

No, that would constitute being mean to people just becuase they're not 
that deep into that matter... (although it is definitely tempting ;-))

Post a reply to this message

triple_r wrote:
> I think the standard answer should just be "Go right ahead!  Come back when
> you're done."
> 
>  - Ricky

standard? standard retarded answer maybe... as I'm proposing this to the 
POV-Team not saying it must be implemented, nor I'm implying I'd 
implement it.

People that doesn't have any pro-active opinions to contribute to the 
discussion should abstain from give it.

Post a reply to this message

clipka wrote:
> Saul Luizaga schrieb:
> (*groans*)

Way to go to start a discussion...

> Sorry, but you violated the "suggetions to use GPU to speed up POV-Ray 
> may (and invariably will) be posted in intervals of 3 months" rule... we 
> just had this discussion about CUDA.
> 
> OpenCL can't change the basic hardware architecture of a GPU; all it 
> does is provide a layer on top (= added overhead!) to faciliate porting 
> existing programs to GPUs - still those programs must be suited to the 
> GPU architecture in order for the added processing power to outweigh the 
> surplus inter-xPU communication overhead, let alone give any speed benefit.

I think you are wrong: "OpenCL (Open Computing Language) greatly 
improves speed and responsiveness for a wide spectrum of applications in 
numerous market categories from gaming and entertainment to scientific 
and medical software."

 From here: 
http://www.khronos.org/news/press/releases/the_khronos_group_releases_opencl_1.0_specification/

Have you appreciated first hand that overhead making it inviable for 
POV-Ray?

> As soon as POV-Ray is fully capable of running a distributed render on a 
> network, it *might* be worth investigating whether the render back-end 
> could also be fully ported to GPUs, to just add some more "machines" to 
> the team. Until then, I don't think it makes much sense to think about 
> it (unless we'd want to develop a completely new render engine using a 
> totally different approach). And even then, question is whether the GPU 
> would be fast enough at the tasks at hand to pay off the effort of 
> getting the code to compile for the GPU.

"Tony Tamasi, senior vice president of technical marketing at NVIDIA 
stated: “OpenCL adds fuel to the most exciting parallel computational 
revolution of our generation – GPU Computing. It also provides another 
powerful way to harness the enormous processing capabilities of our 
CUDA-based GPUs on multiple platforms." From the same link.

Some GPGPU provide 64-bit Floating Point computing wich is, I think, the 
major concern baout raytracing.At the seems some CUDA capable GPUs does 
and for sure some ATI's too:  ATI Stream Technology 
(http://www.amd.com/US/PRODUCTS/TECHNOLOGIES/STREAM-TECHNOLOGY/Pages/stream-technology.aspx).

> 
> OpenCL, however, will definitely *not* be an option, as it is a subset 
> of C (the 3.7 code is written in C++), and has severe limitations that 
> POV-Ray's architecture cannot comply with - most notably that recursions 
> are not allowed. POV-Ray absolutely positively needs recursions to 
> handle secondary rays, and also uses recursive calls for nested 
> definitions of textures pigments or CSG objects.

Granted, this new C standard (C99) is not fully supported in any C++ 
implementations; Intel C++ supports it for the most part but not fully. 
But I think a port to C++ probably is in the making since C++ is by
far more popular than C99 IMHO, so I think, since it has been released 
about 8 months ago, maybe there is a C++ ported OpenCL spec or maybe 
more by now. Many  computing intensive apps. would want this for themselves.

As you may know I participate in WCG (www.worldcommunitygrid.org) a 
scientific research worldwide computing grid for protein-based disease
research like AIDS, Cancer, Human Proteome Folding, etc. There is a 
GPU-based implementation of the Human Proteome Folding project and it 
makes great progress, so I know it works well.

OK, maybe is not as suitable for raytracing as it is for protein folding 
research, maybe the explanation why not is in the discussion about CUDA 
is where the answer is, but maybe is worth it because it has 64-bit 
Floating Point computing, which IIRC is the one and only big obstacle to 
avoid GPU-aided raytracing.

Or what I'm missing? don't want any details, only the highlights if you 
care to answer.

> 
>> PS: I think it should be a 'Suggestions' newsgroup for this sort of 
>> things.
> 
> povray.pov4.discussion.general might be an appropriate spot.

thanks, I think I'll try povray.programming.

Post a reply to this message

Saul Luizaga wrote:
> Or what I'm missing? don't want any details, only the highlights if you 
> care to answer.

Double precision floating point was only the first objection which held 
things up.  For several years we've been saying that it's "the reason", 
but that's just to simplify things as the other reasons don't matter if 
this first one remains unresolved.

Of course, modern GPUs now allow double precision, so we can get to the 
other objections now.  Specifically:

1) Recursion.  As clipka (Christian?) wrote, it is absolutely essential 
for POV.

2) Data parallelization versus code parallelization (this is related to 
the first, but is not strictly the same).

The ray tracing algorithm follows drastically different code branches on 
a single set of data, based on recursion (reflections & refractions), as 
well as the other various computations needed (texture calculation, 
light source occlusion, etc) which almost all need access to the entire 
scene.

Modern CPUs are great for this, as each core is essentially independent, 
yet all may access a common memory pool (the RAM).

Modern GPUs are not only poor for this, but physically incapable of 
running this way.  They are built to run simple procedures on massive 
sets of parallel data (such as rasterization).

Have you ever written a shader for a GPU?  They're extremely limited, 
and you must run *the same shader* on each parallel core.  Whereas each 
core of your CPU can be running an entirely different procedure.

In other words, GPUs are precisely the wrong solution for POV, while 
CPUs are perfect for it.

...Chambers

Post a reply to this message

Saul Luizaga schrieb:
> clipka wrote:
>> (*groans*)
> 
> Way to go to start a discussion...

Sure, but you're really not the first one, and haven't been so recently.

> I think you are wrong: "OpenCL (Open Computing Language) greatly 
> improves speed and responsiveness for a wide spectrum of applications in 
> numerous market categories from gaming and entertainment to scientific 
> and medical software."
> 
>  From here: 
>
http://www.khronos.org/news/press/releases/the_khronos_group_releases_opencl_1.0_specification/


That's a nice statement. Where does it originate from?

Ah, a paper from the group that designed OpenCL to the press. What could 
be their major goal with such a paper? They're not possibly trying 
primarily to get attention to that thing? Right, sure they wouldn't want 
to hype that thing.

Also note that...

- "a wide spectrum of applications" is a very vague statement, and may 
exclude some.

- The categories mentioned all have one thing in common: Massive number 
crunching with few decision making.

POV-Ray does number crunching too, in a sense, but there's a lot of 
desision making involved.

> Have you appreciated first hand that overhead making it inviable for 
> POV-Ray?

How could I? Do you have an OpenCL implementation available for me so 
that I could test it?

But I have read about some limitations of GPU processing in general and 
with regard to raytracing in particular, and imagine to have enough 
understanding of computer architecture to be able to say that data 
exchange between CPU and GPU requires a tad more overhead than 
inter-process communication between separate threads running on the same 
CPU.

> "Tony Tamasi, senior vice president of technical marketing at NVIDIA 
> stated: “OpenCL adds fuel to the most exciting parallel computational 
> revolution of our generation – GPU Computing. It also provides another 
> powerful way to harness the enormous processing capabilities of our 
> CUDA-based GPUs on multiple platforms." From the same link.

Another marketing blurp. Of /course/ the vice president of a big player 
in the GPU market is advertising it as the greatest invention since 
sliced bread: It will sell more of their chips.

> Some GPGPU provide 64-bit Floating Point computing wich is, I think, the 
> major concern baout raytracing.

It used to be one of the major ones, and particularly easy to explain, 
though it's a limitation that is gradually disappearing. I named some 
others in my previous post.

> Granted, this new C standard (C99) is not fully supported in any C++ 
> implementations; Intel C++ supports it for the most part but not fully. 
> But I think a port to C++ probably is in the making since C++ is by
> far more popular than C99 IMHO, so I think, since it has been released 
> about 8 months ago, maybe there is a C++ ported OpenCL spec or maybe 
> more by now. Many  computing intensive apps. would want this for 
> themselves.

I doubt that C++ support is to come anytime soon, given that OpenCL is 
even more limited than C99: No function pointers for instance. How could 
you possibly implement polymorphic objects if you don't even have 
function pointers at your disposal?

If a standard imposes limitations which are more rigorous than what 
you'll find on most brain-dead embedded microcontrollers, then there's a 
hardware reason for it.

> OK, maybe is not as suitable for raytracing as it is for protein folding 
> research, maybe the explanation why not is in the discussion about CUDA 
> is where the answer is, but maybe is worth it because it has 64-bit 
> Floating Point computing, which IIRC is the one and only big obstacle to 
> avoid GPU-aided raytracing.

It used to be the Big One that used to be mentioned first whenever the 
discussion popped up again, and possibly the only thing the POV-Ray 
developers really cared about, historically: Without support for 
double-precision floating point, there was no point in having any closer 
look at GPUs. Fortunately for scientific simulations (like that protein 
folding thing), the precision issue is improving now (probably /because/ 
the GPU developers want to go for that scientific sim market share). 
Howver, other limitations still apply, which are no issue for such use 
cases, but a problem for POV-Ray.

> Or what I'm missing? don't want any details, only the highlights if you 
> care to answer.

No support for recursion is one I named already.

Another one is that GPUs are highly optimized for massively parallel 
computations where exactly the same program with exactly the same 
control flow is run on a vast number of data sets (which is why they 
/can/ be so fast on this type of problems in the first place), but they 
can /only/ run programs of this type; so if program flow must be 
expected to change from one data set to the next, each data set must be 
run on its own, along with (for instance) 31 "empty" data sets: You lose
97% of your processing power. That does not leave much.

Massive parallelization /could/ be used for the primary rays in a scene. 
However, those are not the problem anyway: You only have a few million 
of those, and sophisticated bounding and caching typically keep the 
workload per ray low. It's usually the secondary rays (testing for 
shadows, following reflected and refracted rays, and some such) that eat 
most of the time.


 > thanks, I think I'll try povray.programming.

I had actually and honestly hoped to discourage you with my initial 
groaning. I guess the POV-Ray dev team is better informed about GPU 
computing than you expect.

Post a reply to this message

Chambers schrieb:
> As clipka (Christian?) wrote,

Close to it: Christoph.

Post a reply to this message

Chambers wrote:
> Saul Luizaga wrote:
>> Or what I'm missing? don't want any details, only the highlights if 
>> you care to answer.
> 
> Double precision floating point was only the first objection which held 
> things up.  For several years we've been saying that it's "the reason", 
> but that's just to simplify things as the other reasons don't matter if 
> this first one remains unresolved.
> 
> Of course, modern GPUs now allow double precision, so we can get to the 
> other objections now.  Specifically:
> 
> 1) Recursion.  As clipka (Christian?) wrote, it is absolutely essential 
> for POV.

I suppose this is unsolvable without an C++ ported OpenCL.

> 2) Data parallelization versus code parallelization (this is related to 
> the first, but is not strictly the same).

they say "an API for coordinating data and task-based parallel 
computation...", this doesn't help? If it could do both maybe would be 
of use for POV-Ray.

> The ray tracing algorithm follows drastically different code branches on 
> a single set of data, based on recursion (reflections & refractions), as 
> well as the other various computations needed (texture calculation, 
> light source occlusion, etc) which almost all need access to the entire 
> scene.
> 
> Modern CPUs are great for this, as each core is essentially independent, 
> yet all may access a common memory pool (the RAM).
> 
> Modern GPUs are not only poor for this, but physically incapable of 
> running this way.  They are built to run simple procedures on massive 
> sets of parallel data (such as rasterization).
> 
> Have you ever written a shader for a GPU?  They're extremely limited, 
> and you must run *the same shader* on each parallel core.  Whereas each 
> core of your CPU can be running an entirely different procedure.
> 
> In other words, GPUs are precisely the wrong solution for POV, while 
> CPUs are perfect for it.
> 
> ....Chambers

I see... maybe if GPGPUs are not use as co-processors but as an 
auxiliary co-processor that is called on demand, if GPU compliant 
procedure needs to be processed. Are absolutely sure there isn't a case 
where a GPU can help? maybe in the middle of a rendering/parsing?

Post a reply to this message

clipka wrote:
> Saul Luizaga schrieb:
>> clipka wrote:
>>> (*groans*)
>>
>> Way to go to start a discussion...
> 
> Sure, but you're really not the first one, and haven't been so recently.
> 
>> I think you are wrong: "OpenCL (Open Computing Language) greatly 
>> improves speed and responsiveness for a wide spectrum of applications 
>> in numerous market categories from gaming and entertainment to 
>> scientific and medical software."
>>
>>  From here: 
>>
http://www.khronos.org/news/press/releases/the_khronos_group_releases_opencl_1.0_specification/

> 
> 
> That's a nice statement. Where does it originate from?
> 
> Ah, a paper from the group that designed OpenCL to the press. What could 
> be their major goal with such a paper? They're not possibly trying 
> primarily to get attention to that thing? Right, sure they wouldn't want 
> to hype that thing.
> 
> Also note that...
> 
> - "a wide spectrum of applications" is a very vague statement, and may 
> exclude some.
> 
> - The categories mentioned all have one thing in common: Massive number 
> crunching with few decision making.
> 
> POV-Ray does number crunching too, in a sense, but there's a lot of 
> desision making involved.
> 
>> Have you appreciated first hand that overhead making it inviable for 
>> POV-Ray?
> 
> How could I? Do you have an OpenCL implementation available for me so 
> that I could test it?
> 
> But I have read about some limitations of GPU processing in general and 
> with regard to raytracing in particular, and imagine to have enough 
> understanding of computer architecture to be able to say that data 
> exchange between CPU and GPU requires a tad more overhead than 
> inter-process communication between separate threads running on the same 
> CPU.
> 
>> "Tony Tamasi, senior vice president of technical marketing at NVIDIA 
>> stated: “OpenCL adds fuel to the most exciting parallel computational 
>> revolution of our generation – GPU Computing. It also provides another 
>> powerful way to harness the enormous processing capabilities of our 
>> CUDA-based GPUs on multiple platforms." From the same link.
> 
> Another marketing blurp. Of /course/ the vice president of a big player 
> in the GPU market is advertising it as the greatest invention since 
> sliced bread: It will sell more of their chips.
> 
>> Some GPGPU provide 64-bit Floating Point computing wich is, I think, 
>> the major concern baout raytracing.
> 
> It used to be one of the major ones, and particularly easy to explain, 
> though it's a limitation that is gradually disappearing. I named some 
> others in my previous post.
> 
>> Granted, this new C standard (C99) is not fully supported in any C++ 
>> implementations; Intel C++ supports it for the most part but not 
>> fully. But I think a port to C++ probably is in the making since C++ 
>> is by
>> far more popular than C99 IMHO, so I think, since it has been released 
>> about 8 months ago, maybe there is a C++ ported OpenCL spec or maybe 
>> more by now. Many  computing intensive apps. would want this for 
>> themselves.
> 
> I doubt that C++ support is to come anytime soon, given that OpenCL is 
> even more limited than C99: No function pointers for instance. How could 
> you possibly implement polymorphic objects if you don't even have 
> function pointers at your disposal?
> 
> If a standard imposes limitations which are more rigorous than what 
> you'll find on most brain-dead embedded microcontrollers, then there's a 
> hardware reason for it.
> 
>> OK, maybe is not as suitable for raytracing as it is for protein 
>> folding research, maybe the explanation why not is in the discussion 
>> about CUDA is where the answer is, but maybe is worth it because it 
>> has 64-bit Floating Point computing, which IIRC is the one and only 
>> big obstacle to avoid GPU-aided raytracing.
> 
> It used to be the Big One that used to be mentioned first whenever the 
> discussion popped up again, and possibly the only thing the POV-Ray 
> developers really cared about, historically: Without support for 
> double-precision floating point, there was no point in having any closer 
> look at GPUs. Fortunately for scientific simulations (like that protein 
> folding thing), the precision issue is improving now (probably /because/ 
> the GPU developers want to go for that scientific sim market share). 
> Howver, other limitations still apply, which are no issue for such use 
> cases, but a problem for POV-Ray.
> 
>> Or what I'm missing? don't want any details, only the highlights if 
>> you care to answer.
> 
> No support for recursion is one I named already.
> 
> Another one is that GPUs are highly optimized for massively parallel 
> computations where exactly the same program with exactly the same 
> control flow is run on a vast number of data sets (which is why they 
> /can/ be so fast on this type of problems in the first place), but they 
> can /only/ run programs of this type; so if program flow must be 
> expected to change from one data set to the next, each data set must be 
> run on its own, along with (for instance) 31 "empty" data sets: You lose
> 97% of your processing power. That does not leave much.
> 
> Massive parallelization /could/ be used for the primary rays in a scene. 
> However, those are not the problem anyway: You only have a few million 
> of those, and sophisticated bounding and caching typically keep the 
> workload per ray low. It's usually the secondary rays (testing for 
> shadows, following reflected and refracted rays, and some such) that eat 
> most of the time.
> 

So, you assume that is just a huge amount of hype, and even if it works 
for other apps., won't for POV-Ray. I think there are more to analyze 
than just simple generalizations. Anyway, is a POV/TAG-Team decision, we 
can merely speculate.

>  > thanks, I think I'll try povray.programming.
> 
> I had actually and honestly hoped to discourage you with my initial 
> groaning. I guess the POV-Ray dev team is better informed about GPU 
> computing than you expect.

And you know what I expect the POV/TAG-Team to know... you assume too 
much...

groaning is an emotional response and as such, irrational: I haven't 
been  reading this NG for a long time and the first line of text I read 
was your groaning, besides of the rudeness, it explains nothing, and 
clarifies the same way. I don't like emotional responses to intellectual 
matters, I find them quite out of place, getting in the way of 
logical/rational thinking, making a mess of things, reason enough for me 
to disregard them on sight. Discouraging/intimidating me is not that easy.

Post a reply to this message

On Fri, 14 Aug 2009 03:32:15 -0400, Saul Luizaga <sau### [at] netscapenet> wrote:

>And you know what I expect the POV/TAG-Team to know... 

Is there still a TAG team? I know Warp is still around and Gilles and Ken pop in
occasionally but when was the last time any of the others replied to a post?
-- 

Regards
     Stephen

Post a reply to this message

Stephen wrote:
> On Fri, 14 Aug 2009 03:32:15 -0400, Saul Luizaga <sau### [at] netscapenet> wrote:
> 
>> And you know what I expect the POV/TAG-Team to know... 
> 
> Is there still a TAG team? I know Warp is still around and Gilles and Ken pop in
> occasionally but when was the last time any of the others replied to a post?

No idea man, I assume there is a TAG-Team since I don't think a highly 
technical freeware like this can't exist without one.

Post a reply to this message

Saul Luizaga <sau### [at] netscapenet> wrote:
> groaning is an emotional response and as such, irrational: I haven't 
> been  reading this NG for a long time and the first line of text I read 
> was your groaning, besides of the rudeness, it explains nothing, and 
> clarifies the same way.

  There are certain subjects which repeat themselves time after time when
some people think that they have an ingenious new idea which surely nobody
has even thought of before and thus they come here and write about it. For
the umpteenth time for regulars. Something which has already been discussed
like a million times to death. No wonder regulars are tired of explaining
the same thing over and over.

  At some point in the past, whem XML was all the hype, it was a rather
regular occurrence for someone to come here and suggest that povray's
scene description language would be changed to XML-conforming. No wonder
that after some time people just start responding to it with "no, that's
just a braindead idea" rather than going once again to minute details why
the idea doesn't work.

  To be fair, though, not all such ideas are unimplementable. The most
prominent example is multithreading: In the past it was again and again
suggested, and again and again shot down as unfeasible due to all the
povray features which are not thread-friendly. In a way, both views were
right: Yes, multithreading *is* implementable in povray (as demonstrated),
and yes, it *is* a huge, huge task (as also demonstrated). Not only did it
require an almost complete refactoring of the source code, but even after
all these years there are still minor problems to be solved because of the
problems introduced by multithreading.

  Using the GPU for rendering in povray is equally unfeasible, even though
for slightly different reasons. Mostly it has to do with GPU features (or
lack thereof) and the amount of data which would have to be constantly
transferred between the graphics card and the system RAM, which would most
probably nullify any theoretical speed advantage.

-- 
                                                          - Warp

Post a reply to this message

Chambers wrote:

> Of course, modern GPUs now allow double precision, so we can get to the 
> other objections now.  Specifically:
> 
> 1) Recursion.  As clipka (Christian?) wrote, it is absolutely essential 
> for POV.
> 
> 2) Data parallelization versus code parallelization (this is related to 
> the first, but is not strictly the same).
> 
> The ray tracing algorithm follows drastically different code branches on 
> a single set of data, based on recursion (reflections & refractions), as 
> well as the other various computations needed (texture calculation, 
> light source occlusion, etc) which almost all need access to the entire 
> scene.

There are two problems: recursion and divergence.

When a ray hits something, zero or more secondary rays are spawned. On 
the CPU, this is usually just a recursive function call, but the GPU 
does not permit such a thing.

Also, a GPU consists of *hundreds* of cores, but they must all execute 
the same code path (but with different data). You can set the GPU up to 
process multiple rays, but as soon as some of the rays hit object A but 
others hit object B, the code paths that need to be taken diverge from 
each other, which the GPU does not permit.

The solution in both cases is to put rays into "queues", such that all 
the rays in a given queue take the same code path [for a while]. When 
you need to spawn a secondary ray, you add it to a queue rather than 
recursively tracing it. When some rays hit an object and others don't, 
you add them to different queues. The rays in each queue can then be 
processed in batches later.

The key problem is that if a queue ends up with very few rays in it, 
you're going to have a hell of a lot of idle cores while you process 
that queue. The GPU is usually clocked far slower than the CPU; it only 
"appears" fast because it has hundreds of cores working in parallel. If 
most of those cores are actually idling, you're going to have a problem. 
It may turn out not to be any faster than the CPU under unfavourable 
conditions.

Another possibility is to run the main renderer on the CPU, adding rays 
to queues, and sending any "sufficiently large" queues to the GPU for 
processing. I don't know if bandwidth limitations between the two would 
make this viable...

Post a reply to this message

In article <4a84d512@news.povray.org>,
Saul Luizaga wrote:

> clipka wrote:
>> Saul Luizaga schrieb:
>> (*groans*)
>
> Way to go to start a discussion...

LOL!

Post a reply to this message

Invisible wrote:

I understand perfectly this problems.

> Another possibility is to run the main renderer on the CPU, adding rays 
> to queues, and sending any "sufficiently large" queues to the GPU for 
> processing. I don't know if bandwidth limitations between the two would 
> make this viable...


Exactly, that is why I asked: "Are absolutely sure there isn't a case 
where a GPU can help? maybe in the middle of a rendering/parsing?".

As for the bandwidth and memory concerns, from here: 
http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=95060&enterthread=y

Q: What are AMD's stream computing product features?

A: AMD's FireStreamtm 9170, our latest generation stream computing GPU, 
features:
* 320 stream cores (compute units or ALUs)
* 2GB on-board GDDR3 memory
* Double precision floating point support
* PCIe 2.0 x16 interface
View AMD FireStream 9170 specifications here: 
http://ati.amd.com/products/streamprocessor/specs.html

Memory Concern:
--------------
  Maybe would be a good idea to leave the processed data on the video 
card  local memory until is needed in Main Memory.



Bandwidth Concern:
-----------------
- M4A78 PLUS MoBo 
(http://usa.asus.com/products.aspx?l1=3&l2=149&l3=758&l4=0&model=2889&modelmenu=1):
# It features dual-channel DDR2 1066 memory support and accelerates data 
transfer rate up to 5200MT/s via HyperTransport™ 3.0 based system bus.

- CPU :AMD Phenom™ II Key Architectural Features 
(http://www.amd.com/us/products/desktop/processors/phenom-ii/Pages/phenom-ii-key-architectural-features.aspx)
# One 16-bit link at up to 4000MT/s
# Up to 8.0GB/s HyperTransport™ I/O bandwidth; Up to 16GB/s in 
HyperTransport Generation 3.0 mode
# Up to 37GB/s total delivered processor-to-system bandwidth 
(HyperTransport bus + memory bus)

- PCIe Local Bus: PCIe® Base 2.1 Specification
PCIe Card Electromechanical 2.0 Specification 
(http://www.pcisig.com/specifications/pciexpress/base2)
# Signaling

PCI Express Base 2.0 specification doubles the interconnect bit rate 
from 2.5 GT/s to 5 GT/s in a seamless and compatible manner. The 
performance boost to 5 GT/s is by far the most important feature of the 
PCI Express 2.0 specifications. It effectively increases the aggregate 
bandwidth of a 16-lane link to approximately 16 GB/s.

- Video Card: MD FireStream 9170 (specs above)


----------------- ************** ----------------


As you can see, maybe bandwidth it isn't much of an issue since The 
transfer between the PCIe video card and the Main memory can me made at 
5 GT/s. Is this still insufficient for POV-Ray peak performance?

Post a reply to this message

Warp wrote:
> Saul Luizaga <sau### [at] netscapenet> wrote:
>> groaning is an emotional response and as such, irrational: I haven't 
>> been  reading this NG for a long time and the first line of text I read 
>> was your groaning, besides of the rudeness, it explains nothing, and 
>> clarifies the same way.
> 
>   There are certain subjects which repeat themselves time after time when
> some people think that they have an ingenious new idea which surely nobody
> has even thought of before and thus they come here and write about it. For
> the umpteenth time for regulars. Something which has already been discussed
> like a million times to death. No wonder regulars are tired of explaining
> the same thing over and over.

Well instead of groaning you can make a small .txt file in your PC: 
"Alrady discussed, conclusions were:
1)....
2)...
3)..."
or something like that, to avoid frustration and redundancy.

I don't think my ideas are revolutionary, nor new, nor ingenious, I'm 
just suggesting something that MAY or MAY NOT have not been discussed 
before.

Also I assume everyone here knows more than me, including the 
POV/TAG-Team, so this is more of a hint than a suggestion. Sometimes 
smart people forget about simple things.

>   At some point in the past, whem XML was all the hype, it was a rather
> regular occurrence for someone to come here and suggest that povray's
> scene description language would be changed to XML-conforming. No wonder
> that after some time people just start responding to it with "no, that's
> just a braindead idea" rather than going once again to minute details why
> the idea doesn't work.
> 
>   To be fair, though, not all such ideas are unimplementable. The most
> prominent example is multithreading: In the past it was again and again
> suggested, and again and again shot down as unfeasible due to all the
> povray features which are not thread-friendly. In a way, both views were
> right: Yes, multithreading *is* implementable in povray (as demonstrated),
> and yes, it *is* a huge, huge task (as also demonstrated). Not only did it
> require an almost complete refactoring of the source code, but even after
> all these years there are still minor problems to be solved because of the
> problems introduced by multithreading.

I see, I know POV-Ray source code is HUGE and any minor changes 
represent big efforts. But, at the seems, in this case was a necessary one.

>   Using the GPU for rendering in povray is equally unfeasible, even though
> for slightly different reasons. Mostly it has to do with GPU features (or
> lack thereof) and the amount of data which would have to be constantly
> transferred between the graphics card and the system RAM, which would most
> probably nullify any theoretical speed advantage.
> 

Maybe there is a use for it, not as another main processor but as 
secondary one. I posted about it in another post.

Post a reply to this message

:-D

Post a reply to this message

I mean, the video card has 2GB GDDR3 of RAM and if a suitable threads 
are found for the GPU and all that work can be leaved in the video card 
memory until is needed.

Maybe, even the data in the video card memory could be used to give a 
partial rough preview as the scene is rendered, wouldn't be any clear 
sometimes but it could give you a hint what the GPU is doing on the fly, 
at least I think it would be cool to see it. Probably even won't be too 
much of a delay to display this since is already in he video card. Of 
course this is very optional.

Also I was wondering: what is the bandwidth between the CPU and the Main 
Memory at render time? maybe this can help us calculate a rough estimate 
of the bandwidth needed for the video card.

Cheers.

Post a reply to this message

Saul Luizaga schrieb:
>> 1) Recursion.  As clipka (Christian?) wrote, it is absolutely 
>> essential for POV.
> 
> I suppose this is unsolvable without an C++ ported OpenCL.

???
Recursion is not a feature of C++, it is also a part of standard C99.

>> 2) Data parallelization versus code parallelization (this is related 
>> to the first, but is not strictly the same).
> 
> they say "an API for coordinating data and task-based parallel 
> computation...", this doesn't help? If it could do both maybe would be 
> of use for POV-Ray.

Did you actually /read/ the spec - or just the enthusiastic introduction?

Sure, it does support task-based parallel computation - why? Probably 
because it also targets classic multi-core CPUs, which are ideally 
suited to task-based parallel computing.

GPUs perform very poorly with task-based parallel computations, due to 
their hardware architecture. A software abstraction layer won't change 
that fundamental limitation.

> I see... maybe if GPGPUs are not use as co-processors but as an 
> auxiliary co-processor that is called on demand, if GPU compliant 
> procedure needs to be processed. Are absolutely sure there isn't a case 
> where a GPU can help? maybe in the middle of a rendering/parsing?

No.

POV-Ray's internal workflow does not support asynchronous computations 
(other than having multiple threads independently render parts of the 
image), so only blocking "calls" to the GPU would be of any use, putting 
the CPU task in waiting state in the meantime. Therefore, only portions 
of the code that can be computed /significantly/ faster by the GPU, or 
have any /significant/ size, would warrant "outsourcing" of 
computations, otherwise parameter passing and task switching overhead 
would bog down performance instead of increasing it.

But the only sections of POV-Ray code that do ask for parallelization 
are RGB color and 3D vector computations, or similarly-sized problems; 
these can be parallelized quite well on modern CPUs as well using SSE2 
(i.e. the GPU will not be much faster), and are heavily intermixed with 
conditional branching (i.e. the size of outsourceable work packages is 
very small)

Post a reply to this message

Saul Luizaga schrieb:
>> Another possibility is to run the main renderer on the CPU, adding 
>> rays to queues, and sending any "sufficiently large" queues to the GPU 
>> for processing. I don't know if bandwidth limitations between the two 
>> would make this viable...
> 
> Exactly, that is why I asked: "Are absolutely sure there isn't a case 
> where a GPU can help? maybe in the middle of a rendering/parsing?".

Note that although the approach /may/ (!) work, it is a /fundamentally/ 
different approach from what POV-Ray is doing.

Changing POV-Ray to use that approach would imply virtually a complete 
rewrite of the render engine.

> As you can see, maybe bandwidth it isn't much of an issue since The 
> transfer between the PCIe video card and the Main memory can me made at 
> 5 GT/s. Is this still insufficient for POV-Ray peak performance?

So you're looking at peak data transfer rate limits and from them can 
infer that transfer between CPU and GPU memory space is not an issue?

Did you consider latency issues, or the overhead created by the OpenCL 
framework itself? How about the latency for a "function call"?

If your work packages are large enough, then these are no issues. But in 
a raytracer, be prepared for rather small work packages.

Post a reply to this message

Saul Luizaga schrieb:
> So, you assume that is just a huge amount of hype, and even if it works 
> for other apps., won't for POV-Ray. I think there are more to analyze 
> than just simple generalizations.

I didn't see much analyzing on your side - only enthusiasm about what 
they write in the introduction. It appears to me that you don't know 
much about POV-Ray's architecture or GPU architecture, and are actually 
not too familiar with the OpenCL framework either.

I'm not generalizing. I did have a look at the paper, and analyzed it 
(and POV-Ray's program structure) in enough detail to present hard facts 
why POV-Ray and OpenCL won't mix, at least not at the time being.


 > Anyway, is a POV/TAG-Team decision, we can merely speculate.

No, we can say for sure that they will /not/ go for OpenCL anytime near.


>> I had actually and honestly hoped to discourage you with my initial 
>> groaning. I guess the POV-Ray dev team is better informed about GPU 
>> computing than you expect.
> 
> And you know what I expect the POV/TAG-Team to know... you assume too 
> much...

 From your postings, it is quite obvious that you assumed OpenCL to be 
something brand new, with you being the first in all the POV-Ray 
community to discover it.

FYI: OpenCL has been mentioned in the POV-Ray NGs half a year ago already.


> groaning is an emotional response and as such, irrational: I haven't 
> been  reading this NG for a long time and the first line of text I read 
> was your groaning, besides of the rudeness, it explains nothing, and 

And that's exactly why I issued this loud groan: You /obviously/ didn't 
even bother to check whether anyone ever brought up the topic of GPU 
usage any time recently, or you would have noticed that it had just been 
on the agenda again, in the incarnation of CUDA.

Even after you were informed that the topic had been discussed just 
recently, you also obviously haven't bothered to check the thread on 
that topic, to get yourself updated on the problems of using GPUs with 
POV-Ray, and compare how that applies to OpenCL.

You just came stumbling in, hollering "hey, I got this great perfect 
idea for POV-Ray...", as if the people developing POV-Ray would never 
have heard of it otherwise. Even upon receiving a not-so-positive 
reaction indicating that you /might/ be wrong, you stuck to that 
attitude, hollering right away again in p.programming in the same style. 
There's rudeness in that, too.

Post a reply to this message

Saul Luizaga schrieb:
> Well instead of groaning you can make a small .txt file in your PC: 
> "Alrady discussed, conclusions were:
> 1)....
> 2)...
> 3)..."
> or something like that, to avoid frustration and redundancy.

What, and have it clutter my hard disk, and three months later when it's 
really needed I don't remember where I put it?

Furthermore, as is just being demonstrated, people don't take the 
explanations and leave it be, but start discussions about it. Or they 
don't understand the explanations and ask. Or...


> I don't think my ideas are revolutionary, nor new, nor ingenious, I'm 
> just suggesting something that MAY or MAY NOT have not been discussed 
> before.

Next time you're in that situation, you might as well /check/ if it has 
been discussed before.

> Also I assume everyone here knows more than me, including the 
> POV/TAG-Team, so this is more of a hint than a suggestion. Sometimes 
> smart people forget about simple things.

Reread your original post. It doesn't sound like what you describe now.


> I see, I know POV-Ray source code is HUGE and any minor changes 
> represent big efforts.

Not really. Major changes represent major efforts. As of now, GPU 
support would be a more-than-major effort.

/Some/ changes that look like minor ones do require big efforts due to 
how the internal structure happens to be. Others appear like a major one 
  but are actually a piece of cake to implement.


> Maybe there is a use for it, not as another main processor but as 
> secondary one. I posted about it in another post.

Maybe it's worth reconsidering in a year or so.

Post a reply to this message

clipka wrote:
> If your work packages are large enough, then these are no issues. But in 
> a raytracer, be prepared for rather small work packages.

And that's another problem.  While a GPU has *hundreds* of cores that 
all work in parallel, in raytracing you're unlikely to encounter more 
than a few dozen rays which require the same test.  It's just not 
efficient to solve this problem with GPUs.

Note that, while GPGPU has come a long way in recent years, the only way 
to make it more useful for POV is to make it more like a CPU and less 
like a GPU.  While GPUs in general may go this route in the future (Tim 
Sweeney thinks so), really GPUs will focus first and foremost on what 
games need... and games don't need raytracing yet.

...Chambers

Post a reply to this message

Saul Luizaga wrote:
> So, you assume that is just a huge amount of hype, and even if it works 
> for other apps., won't for POV-Ray.

NB: There are some apps, which theoretically *should* benefit massively 
from GPGPU, which are actually hurt by it.

Case in point: TMPGEnc, using CUDA.  Video encoding has long been touted 
as one of the best areas for improvement via GPGPU.

On a GeForce 260, it's actually *slower* than a Core 2 Quad 6600 (2.4gHz).

Imagine a dual-processor six-core Xeon system (12 cores, 24 threads) and 
you'd need a few dozen GPUs (running literally *thousands* of threads) 
to match the performance.

...Chambers

Post a reply to this message

clipka wrote:

> Note that although the approach /may/ (!) work, it is a /fundamentally/ 
> different approach from what POV-Ray is doing.
> 
> Changing POV-Ray to use that approach would imply virtually a complete 
> rewrite of the render engine.

Agreed. It's no small task, by any stretch of the imagination...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> If your work packages are large enough, then these are no issues. But 
>> in a raytracer, be prepared for rather small work packages.
> 
> And that's another problem.  While a GPU has *hundreds* of cores that 
> all work in parallel, in raytracing you're unlikely to encounter more 
> than a few dozen rays which require the same test.  It's just not 
> efficient to solve this problem with GPUs.

I'm not sure I agree with these statements.

Tracing a scene involves shooting thousands, or even tens of thousands 
of rays at the top-level geometry. While there may be some objects which 
are quite small, most objects will be hit by hundreds and hundreds of rays.

Now, whether it's efficient to run the entire rendering engine on the 
GPU is debatable, but it would seem to be that it should be possible to 
achieve *some* speedup by running at least part of the tracing process 
on the GPU. (The only question is bandwidth.)

> Note that, while GPGPU has come a long way in recent years, the only way 
> to make it more useful for POV is to make it more like a CPU and less 
> like a GPU.  While GPUs in general may go this route in the future (Tim 
> Sweeney thinks so), really GPUs will focus first and foremost on what 
> games need... and games don't need raytracing yet.

More to the point, if a GPU was more like a CPU, it wouldn't be faster 
than a CPU.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
>>> If your work packages are large enough, then these are no issues. But 
>>> in a raytracer, be prepared for rather small work packages.
>>
>> And that's another problem.  While a GPU has *hundreds* of cores that 
>> all work in parallel, in raytracing you're unlikely to encounter more 
>> than a few dozen rays which require the same test.  It's just not 
>> efficient to solve this problem with GPUs.
> 
> I'm not sure I agree with these statements.
> 
> Tracing a scene involves shooting thousands, or even tens of thousands 
> of rays at the top-level geometry. While there may be some objects which 
> are quite small, most objects will be hit by hundreds and hundreds of rays.

Let's say a scene rendered for display on a 1080p TV has approximately 
300 objects in it, each one covering a similar portion of the display 
(for simplicity's sake).

That's a total of 1,920x1,080=2,073,600 pixels, or 6,912 for each 
object.  Admittedly, this is more than my statement of "a few dozen" :) 
  However, each level of recursion will split the groups rays - let's 
say into 4 groups (I honestly think they would be grouped in more, 
smaller, groups, but this will make the math easier).  After only 4 
levels of recursion (a value entirely common in scenes) the rays are 
bundled in groups of 25 (assuming an even distribution, of course).

With a smaller image, more objects, and less tight grouping, you'd get 
such small groups after only one or two levels of recursion.

> More to the point, if a GPU was more like a CPU, it wouldn't be faster 
> than a CPU.

True ;)

...Chambers

Post a reply to this message

> After only 4 levels of 
> recursion (a value entirely common in scenes) the rays are bundled in 
> groups of 25 (assuming an even distribution, of course).
> 
> With a smaller image, more objects, and less tight grouping, you'd get 
> such small groups after only one or two levels of recursion.

That seems small enough that it might be worth transferring back to the CPU.

But if you think about common scenes where you have walls and floors and 
so forth, it might be worth using the GPU to test ray intersections 
against these, and against bounding volumes (if you're using them). Huge 
numers of rays need to be run through these tests, so the GPU can fire 
those off quite quickly. It might also be worth running the "so what the 
hell is the colour of this surface?" calculation on the GPU - what with 
texturing, normal maps, multiple light rays of different angles and 
colours, etc.

Also, let's clear this up: My understanding is that the GPU does not 
require *all* cores to run an identical kernel. IIRC, the cores are 
grouped into (fairly large) bundles, each bundle runs a single kernel, 
but different bundles can run completely different kernels. So you don't 
need a ray queue with enough rays for the entire GPU, just for a whole 
bundle of cores.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> But if you think about common scenes where you have walls and floors and 
> so forth, it might be worth using the GPU to test ray intersections 
> against these, and against bounding volumes (if you're using them). Huge 
> numers of rays need to be run through these tests, so the GPU can fire 
> those off quite quickly.

But those tests are also quite simple, so would benefit the least from 
the GPU.  If isosurfaces could be translated efficiently into shaders, 
then those would show the most benefit (and Julia fractals, of course).

> It might also be worth running the "so what the 
> hell is the colour of this surface?" calculation on the GPU - what with 
> texturing, normal maps, multiple light rays of different angles and 
> colours, etc.

Possibly.  In fact, using the GPU for GI might be an option.  For 
instance, we could run a single extremely high resolution pass with no 
lighting or texturing, just intersections, and cache all the 
intersection locations.  Then, feed these intersections to the GPU, and 
have it calculate lighting for those points.  Feed the lighting data 
back to the CPU for radiosity, and voila!  Fast GI :)  (Of course, 
implementing it would be a b*tch, but that's beside the point).

> Also, let's clear this up: My understanding is that the GPU does not 
> require *all* cores to run an identical kernel. IIRC, the cores are 
> grouped into (fairly large) bundles, each bundle runs a single kernel, 
> but different bundles can run completely different kernels. So you don't 
> need a ray queue with enough rays for the entire GPU, just for a whole 
> bundle of cores.

True, I think the shaders are in blocks of 4, and you have to have 
groups of 32 blocks running the same shader or something like that 
(which would be 128 shaders per program).  I don't remember the exact 
numbers, though, and in fact it's probably GPU dependent.

...Chambers

Post a reply to this message

clipka wrote:
> Saul Luizaga schrieb:
>>> Another possibility is to run the main renderer on the CPU, adding 
>>> rays to queues, and sending any "sufficiently large" queues to the 
>>> GPU for processing. I don't know if bandwidth limitations between the 
>>> two would make this viable...
>>
>> Exactly, that is why I asked: "Are absolutely sure there isn't a case 
>> where a GPU can help? maybe in the middle of a rendering/parsing?".
> 
> Note that although the approach /may/ (!) work, it is a /fundamentally/ 
> different approach from what POV-Ray is doing.
> 
> Changing POV-Ray to use that approach would imply virtually a complete 
> rewrite of the render engine.
> 
>> As you can see, maybe bandwidth it isn't much of an issue since The 
>> transfer between the PCIe video card and the Main memory can me made 
>> at 5 GT/s. Is this still insufficient for POV-Ray peak performance?
> 
> So you're looking at peak data transfer rate limits and from them can 
> infer that transfer between CPU and GPU memory space is not an issue?
> 
> Did you consider latency issues, or the overhead created by the OpenCL 
> framework itself? How about the latency for a "function call"?
> 
> If your work packages are large enough, then these are no issues. But in 
> a raytracer, be prepared for rather small work packages.

You just don't like to be corrected due to your intellectual vanity and 
arrogance, leave those aside for good, they don't do anybody any good.

I made a search on p.o-t on the subject and found nothing. The question 
was: "are you ABSOLUTELY SURE it won't work...?" First you say NO. then 
MAY (!) work. Obvious contradiction. Then you made a number of 
assumptions (againg) about me, all of them WRONG and this is for sure 
rude. Posting on p.p was only the right thing to do, since it was a 
suggestion I didn't started a discussion there, but here.

On my first post in this thread: get some perspective dude, it was for 
everyone, from little tech knowledge to the most advanced, of course 
most advanced readers can obvious the explanation/clarification I made 
about OpenCL.

To the subject: I don't know much about GPUs, POV-Ray internals, 
programming, nor OpenCL, but I do know a little about Computer 
electronic architecture. Some of the questions I made are not meant for 
this NG readers not even the TAG-Team but to the POV-Team, so they can 
made calculations about OpenCL.

I think they may have a structured and classified diagram of ALL POV-Ray 
programming structures, knowing approximately how much each structure 
would take in the CPU, so from the data I provided they could see:

1) What GPU capable structures.
2) The amount of time that the selected GPU capable structures could 
take to do a given process.
3) And this should be first, see if it is worth it, to consider the GPU 
aid, if not possible through OpenCL, make a custom framework. If it is, 
calculate how many GPU capable structures there are to have a second 
evaluation, and see if that number is worth the effort.
4) ETC.

So I'm analyzing to the best of my abilities as everyone here, including 
you, but you're taking this too emotional and going for personal attacks 
on me trying to discredit me. I'm just trying to see all possibilities 
of GPU acceleration and have a discussion and maybe lighten up the 
analysis a little for the POV-Team, but maybe is not me place nor even 
non POV-TAG-Team people, so maybe I should just had this addressed to 
the POV-Team for their consideration only and avoid so much "bothering" 
people here. But as you can see there are somethings to say about it 
still...

Post a reply to this message

Saul Luizaga wrote:
> You just don't like to be corrected

This sounds more like you.

Believe it or not, this subject is an official Dead Horse.  Please stop 
beating it, you'll only get a bloody mess.

> I made a search on p.o-t on the subject

First, p.o-t is the wrong forum.
Second, posts here expire.

> was: "are you ABSOLUTELY SURE it won't work...?"

No, you didn't even ask a question.  You made a statement: "I have just 
learned about it and I think this could be a great improvement for POV-ray"

This is something which, by your own words, you have just heard about. 
You then quoted a whole bunch of marketing blurbs about it.

Trust me.  We have not just heard about it, but have been looking at the 
idea for more than *10 years* now.  I haven't specifically looked at 
OpenCL, but I have CUDA, and the underlying hardware hasn't changed 
enough yet to overcome the inherent limitations in the system.

> To the subject: I don't know much about GPUs, POV-Ray internals, 
> programming, nor OpenCL,

Then why is it so hard for you to accept that this isn't a good idea at 
this time?

If you really want to help make POV-Ray better, the source code is 
available.  Please, dig in!  Start reading the p.p group, and look at 
some of the outstanding bugs!  That would surely be appreciated more 
than your parroting some random marketing blurbs.

...Chambers

Post a reply to this message

Chambers wrote:
> Saul Luizaga wrote:
>> You just don't like to be corrected
> 
> This sounds more like you.

right...

> 
> Believe it or not, this subject is an official Dead Horse.  Please stop 
> beating it, you'll only get a bloody mess.
> 
>> I made a search on p.o-t on the subject
> 
> First, p.o-t is the wrong forum.
> Second, posts here expire.
> 
>> was: "are you ABSOLUTELY SURE it won't work...?"
> 
> No, you didn't even ask a question.

news://news.povray.org:119/4a850da7@news.povray.org, check the last 
paragraph, proves you wrong. Did you liked to be corrected?

> 
> This is something which, by your own words, you have just heard about. 
> You then quoted a whole bunch of marketing blurbs about it.
> 
> Trust me.  We have not just heard about it, but have been looking at the 
> idea for more than *10 years* now.  I haven't specifically looked at 
> OpenCL, but I have CUDA, and the underlying hardware hasn't changed 
> enough yet to overcome the inherent limitations in the system.
> 
>> To the subject: I don't know much about GPUs, POV-Ray internals, 
>> programming, nor OpenCL,
> 
> Then why is it so hard for you to accept that this isn't a good idea at 
> this time?
> 
> If you really want to help make POV-Ray better, the source code is 
> available.  Please, dig in!  Start reading the p.p group, and look at 
> some of the outstanding bugs!  That would surely be appreciated more 
> than your parroting some random marketing blurbs.
> 
> ....Chambers

So open minded... thanks, I out of here for good.

Post a reply to this message

Saul Luizaga wrote:
>> No, you didn't even ask a question.
> 
> news://news.povray.org:119/4a850da7@news.povray.org, check the last 
> paragraph, proves you wrong. Did you liked to be corrected?

Yes, I do as a matter of fact.  I don't like being wrong.

...Chambers

Post a reply to this message

Saul Luizaga schrieb:
> I made a search on p.o-t on the subject and found nothing.

This may be because p.o-t is actually not the best place for such a 
posting, as it is intended for topics /not/ related to POV-Ray.


 > The question
> was: "are you ABSOLUTELY SURE it won't work...?" First you say NO. then 
> MAY (!) work. Obvious contradiction.

You're quoting me out of context, and out of chronological order.

You proposed OpenCL for POV-Ray. If you go back to my first reply, 
you'll find that my answer was manifold back then already - but not 
contradictory (nor were my follow-ups):


(I) *NO*, OpenCL will *not* be an option for POV-Ray, because (a) it is 
written in a different language (namely C++), and (b) the internal 
architecture makes heavy use of constructs not available in OpenCL (most 
particularly recursions).

Both of this still stands. If you have any substantial information that 
make both of these arguments moot (other than wishful thinking about 
where the OpenCL project /may/ be heading some time in the future 
according to your imagination), then go ahead and correct me.

There is another point in which I might be mistaken: My argument is 
based on assumptions that (a) POV-Ray will not go back to C again, and 
(b) the fundamental architecture will not change anytime soon. However, 
given that POV-Ray has /just been/ ported from C to C++, and the feat of 
adding SMP support has /already/ taken something like 3 years, I don't 
expect any strong urge to introduce even more fundamental changes in the 
underlying architecture.

This urge /might/ be greater if there was a clear promise of benefit. 
However, even /that/ is still doubtful.


(II) Yes, it *MIGHT* be possible to run a full-fledged independent 
POV-Ray thread on a GPU; however, this would require some conditions to 
be fulfilled first:

(1) POV-Ray would /first/ have to be brought to the point where it can 
run distributed renders on multiple machines.

The reason here is that in order to run a separate thread on the GPU, 
POV-Ray would need to be enabled to run render threads in fully separate 
(or at least non-synchronized) address spaces. As this is also /the/ 
main prerequisite for distrubuted rendering on multiple machines (in 
this multiprocessing model, communication bandwidth and latency are 
likely to pose not so much of a problem even in the network, let alone 
between CPU and GPU), and network rendering is already a goal POV-Ray is 
committed to, I do /not/ expect GPU support to be tackled any time 
earler: Network rendering comes with a clear promise of a fair gain in 
render speed and usability, while the benefit of GPU rendering is still 
carrying a big question mark.

(2) Someone would have to come up with a GPU programming framework much 
better suited to POV-Ray, which eliminates all the issues in (I), i.e. 
supports C++ and recursions.


(III) With the intention of elaborating on (I), I noted that yes, it 
*MIGHT* be possible to include GPU support via OpenCL use in POV-Ray 
even without changing the fundamental structure of the application, 
*BUT* this would /very/ likely lead to worse performance than without 
the GPU support, due to (a) the inability of POV-Ray to supply the GPU 
with a large enough and parallelizable work package, and (b) the 
inability of POV-Ray to continue while the GPU is processing that work 
package.


As a resume, I still am perfectly sure that OpenCL is *not* currently an 
option to speed up POV-Ray.

Plus, I am perfectly sure that OpenCL will be further revisited now and 
then, and reconsidered as an option, should it be improved to the point 
where it appears to make some sense.


> To the subject: I don't know much about GPUs, POV-Ray internals, 
> programming, nor OpenCL, but I do know a little about Computer 
> electronic architecture. Some of the questions I made are not meant for 
> this NG readers not even the TAG-Team but to the POV-Team, so they can 
> made calculations about OpenCL.

There's not much that can be calculated from your figures, except the 
peak memory transfer rate of some - presumably - representative graphics 
hardware. Program execution speed, however, also depends on the 
particular compiler (and optimizer!) - which are not even available yet.

> I think they may have a structured and classified diagram of ALL POV-Ray 
> programming structures, knowing approximately how much each structure 
> would take in the CPU, so from the data I provided they could see:

That would help in no way, because these structures all rely on an 
architecture that, as already pointed out, is fundamentally incompatible 
with OpenCL-based GPU computing.

> 3) And this should be first, see if it is worth it, to consider the GPU 
> aid, if not possible through OpenCL, make a custom framework. If it is, 
> calculate how many GPU capable structures there are to have a second 
> evaluation, and see if that number is worth the effort.

I don't think that the POV-Ray dev team should even be bothered with 
this, because from all I see, current GPU architectures would appear to 
either require a /monstrous/ amount of framework development to make it 
work for /POV-Ray/ (again, most particularly due to the lack of support 
for recursion, which apparently is a hardware limitation, not a 
framework thing), or provide /very small/ gain or even a disadvantage 
(due to the small size of work packages POV-Ray could supply to the GPU, 
and the lack of POV-Ray to do anything else while waiting for the 
results), or require a /monstrous/ amount of POV-Ray architecture changes.

I don't think the POV-Ray dev team /want/ to be bothered (once again) 
with this anyway.

And even /if/ they wanted to be bothered, /I/ as a POV-Ray user wouldn't 
want them to, because I think there are plenty of features which are 
more important to invest time into, where a gain is clearly visible, 
while the gain of GPU support is still /very/ questionable, for all the 
reasons I (and others) have presented by now.

Post a reply to this message

Saul Luizaga schrieb:
>>> was: "are you ABSOLUTELY SURE it won't work...?"
>>
>> No, you didn't even ask a question.
> 
> news://news.povray.org:119/4a850da7@news.povray.org, check the last 
> paragraph, proves you wrong. Did you liked to be corrected?

Are you actually aware that Chambers and CLipka are two totally 
different persons? That there are actually /two/ persons trying to 
convince you that OpenCL will get POV-Ray nowhere (with others having 
joined in occasionally)?

Maybe you should re-read all the replies you got, and have a look at who 
actually wrote them, and what you replied to whom.


And Chambers is right: There wasn't a question to start with. You only 
went for a more questioning style some postings into the discussion.

Post a reply to this message

>> But if you think about common scenes where you have walls and floors 
>> and so forth, it might be worth using the GPU to test ray 
>> intersections against these, and against bounding volumes (if you're 
>> using them). Huge numers of rays need to be run through these tests, 
>> so the GPU can fire those off quite quickly.
> 
> But those tests are also quite simple, so would benefit the least from 
> the GPU.

How do you figure that?

The benefit of the GPU isn't the complexity of the kernels it executes 
(usually quite the converse), it's more the fact that it can do the same 
operations many, many times over simultaneously.

> If isosurfaces could be translated efficiently into shaders, 
> then those would show the most benefit (and Julia fractals, of course).

No arguments here.

>> It might also be worth running the "so what the hell is the colour of 
>> this surface?" calculation on the GPU - what with texturing, normal 
>> maps, multiple light rays of different angles and colours, etc.
> 
> Possibly.  In fact, using the GPU for GI might be an option.

Yes, there's a couple of ways you might implement this, with varying 
degrees of accuracy. For example, you could feed the GPU a polygon mesh 
approximating the scene. (There are already known algorithms for doing 
GI on a polygon mesh.) Or you could just use the GPU to accelerate the 
insane number of ray intersection tests required during GI.

>> Also, let's clear this up: My understanding is that the GPU does not 
>> require *all* cores to run an identical kernel. IIRC, the cores are 
>> grouped into (fairly large) bundles, each bundle runs a single kernel, 
>> but different bundles can run completely different kernels. So you 
>> don't need a ray queue with enough rays for the entire GPU, just for a 
>> whole bundle of cores.
> 
> True, I think the shaders are in blocks of 4, and you have to have 
> groups of 32 blocks running the same shader or something like that 
> (which would be 128 shaders per program).  I don't remember the exact 
> numbers, though, and in fact it's probably GPU dependent.

Yeah, I'm pretty sure the batch sizes vary by GPU model. But the main 
point is, you don't have to assign *all* cores to the same kernel; just 
sufficiently large bunches of them.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
>> But those tests are also quite simple, so would benefit the least from 
>> the GPU.
> 
> How do you figure that?

Because you need to look at the ratio of computation time to 
transmission time.  The simpler something is, the lower the ratio, and 
the less worthwhile offloading is (after all, it messes with the cache, 
the bus, the memory system, etc).  Ideally, whatever you offload will be 
computationally intensive, so the transmission time is justifiable.

> Yeah, I'm pretty sure the batch sizes vary by GPU model. But the main 
> point is, you don't have to assign *all* cores to the same kernel; just 
> sufficiently large bunches of them.

The key, of course, being "sufficiently large bunches."  There's a 
strong likelihood that POV wouldn't be able to consistently create 
batches that are sufficiently large.

...Chambers

Post a reply to this message

Chambers wrote:

> The key, of course, being "sufficiently large bunches."  There's a 
> strong likelihood that POV wouldn't be able to consistently create 
> batches that are sufficiently large.

This is the key question, yes.

Post a reply to this message

> 1) Recursion.  As clipka (Christian?) wrote, it is absolutely essential 
> for POV.
>
> 2) Data parallelization versus code parallelization (this is related to 
> the first, but is not strictly the same).
>
> The ray tracing algorithm follows drastically different code branches on a 
> single set of data, based on recursion (reflections & refractions), as 
> well as the other various computations needed (texture calculation, light 
> source occlusion, etc) which almost all need access to the entire scene.

Often you need to drastically change your algorithm to get it running well 
on a GPU.  It's quite trivial to rewrite the raytracing algorithm to work on 
masses of rays in parallel with no branching or ray spawning, and then do 
the branching/spawning for the rays all in one go.  After this you can 
efficiently use the GPU and CPU in parallel.

Post a reply to this message

> The solution in both cases is to put rays into "queues", such that all the 
> rays in a given queue take the same code path [for a while]. When you need 
> to spawn a secondary ray, you add it to a queue rather than recursively 
> tracing it. When some rays hit an object and others don't, you add them to 
> different queues.

Why add it to a different queue?  All rays that still need to be traced 
(whether they are reflection, refraction, primary or shadow rays) simply 
need to be intersected with the scene geometry.  If you like you could keep 
a flag in the queue for each ray to say what type it is, but the GPU part 
that does the ray-scene intersection probably doesn't care what sort of ray 
it is.

In that way the GPU will just process as many rays as it can in batches 
until the scene is complete.  The CPU would handle preparing the queue at 
each step, ie removing rays that have terminated and inserting new rays for 
shadows and reflections etc.

Of course to be able to do efficient scene intersection on the GPU it would 
probably be best to only allow triangle-based scenes, and figure out some 
way to store a Kd-tree of triangles efficiently in a texture.  Sounds like 
the sort of thing someone has already done a PhD on :-)

Post a reply to this message

scott wrote:
>> When some rays hit an object and others don't, 
>> you add them to different queues.
> 
> Why add it to a different queue?  All rays that still need to be traced 
> (whether they are reflection, refraction, primary or shadow rays) simply 
> need to be intersected with the scene geometry.

I was thinking more along the lines of each surface possibly having a 
different code path for computing illumination. Rays in the same bundle 
can't take different code paths.

> In that way the GPU will just process as many rays as it can in batches 
> until the scene is complete.  The CPU would handle preparing the queue 
> at each step, ie removing rays that have terminated and inserting new 
> rays for shadows and reflections etc.

Depends on whether you're thinking of running the whole computation on 
the GPU, or just the ray intersection tests, or what.

> Of course to be able to do efficient scene intersection on the GPU it 
> would probably be best to only allow triangle-based scenes

I see no especial reason why you can't do arbitrary intersection tests 
on a GPU. The math isn't that complicated. The only real problem is 
going to be trying to run something like isosurfaces, which use adaptive 
space division; a GPU probably won't like that. But something like a 
Newton iteration should be fine. [That obviously isn't applicable to 
general isosurfaces though...]

> and figure 
> out some way to store a Kd-tree of triangles efficiently in a texture.

Also depends on whether you're trying to write your code as a shaper, or 
use a real GPGPU system. (Such as the OpenCL in the title.)

> Sounds like the sort of thing someone has already done a PhD on :-)

Indeed, that's where I read about the render queue approach. (No, I 
don't remember where *exactly*.)

Post a reply to this message

> I was thinking more along the lines of each surface possibly having a 
> different code path for computing illumination. Rays in the same bundle 
> can't take different code paths.

Sure they can, you just have an "if" in the shader code based on some flag 
in the ray data.

> Depends on whether you're thinking of running the whole computation on the 
> GPU, or just the ray intersection tests, or what.

Some things I think the CPU still needs to do, like preparing the ray data 
to put on the GPU at each step. It is quite hard to write a shader that does 
anything other than return one "output value" per "pixel", ie you can't 
write a shader that returns a veriable number of rays, the only thing you 
can do is return a flag set that means "spawn another ray".

> I see no especial reason why you can't do arbitrary intersection tests on 
> a GPU. The math isn't that complicated.

I was thinking more about how to store the scene on the GPU efficiently, if 
you just have a triangle list it is relatively simple.

> The only real problem is going to be trying to run something like 
> isosurfaces, which use adaptive space division; a GPU probably won't like 
> that.

Nah it's no problem :-)  Modern GPUs don't have any limit on loops or number 
of instructions or anything like that.

> Also depends on whether you're trying to write your code as a shaper, or 
> use a real GPGPU system. (Such as the OpenCL in the title.)

I think something like a raytracer will be too complicated for a computer to 
try and figure out how to put it on the GPU the best way, needs to be hand 
coded by an intelligent person :-)

> Indeed, that's where I read about the render queue approach. (No, I don't 
> remember where *exactly*.)

Damn.  If you think up *anything* you think is new, you can be guaranteed 
that someone else somewhere has already thought of it :-)  The internet just 
makes it easy to find that person!

Post a reply to this message

>> I was thinking more along the lines of each surface possibly having a 
>> different code path for computing illumination. Rays in the same 
>> bundle can't take different code paths.
> 
> Sure they can, you just have an "if" in the shader code based on some 
> flag in the ray data.

I was under the impression that all cores in the bunch would have to 
take the same branch of the if - you can't have half go one way and half 
go the other. (That's what makes it a SIMD architecture.)

I was also under the impression you can have predicated instructions, 
however. (I.e., a single instruction that executes or doesn't based on a 
condition. But not a whole alternate execution path.)

> Some things I think the CPU still needs to do, like preparing the ray 
> data to put on the GPU at each step. It is quite hard to write a shader 
> that does anything other than return one "output value" per "pixel", ie 
> you can't write a shader that returns a veriable number of rays, the 
> only thing you can do is return a flag set that means "spawn another ray".

> I was thinking more about how to store the scene on the GPU efficiently, 
> if you just have a triangle list it is relatively simple.

Again, depends on whether you're writing a shader, or using a GPGPU system.

>> The only real problem is going to be trying to run something like 
>> isosurfaces, which use adaptive space division; a GPU probably won't 
>> like that.
> 
> Nah it's no problem :-)  Modern GPUs don't have any limit on loops or 
> number of instructions or anything like that.

But they don't allow recursion. That's the issue.

>> Also depends on whether you're trying to write your code as a shaper, 
>> or use a real GPGPU system. (Such as the OpenCL in the title.)
> 
> I think something like a raytracer will be too complicated for a 
> computer to try and figure out how to put it on the GPU the best way, 
> needs to be hand coded by an intelligent person :-)

...and?

All GPGPU does is allow you to run programs on a GPU which don't 
necessarily have to be shaped like shaders. You still have to write the 
code yourself. It's just that you don't have to pretend it's 
graphics-related even if it isn't.

> Damn.  If you think up *anything* you think is new, you can be 
> guaranteed that someone else somewhere has already thought of it :-)  
> The internet just makes it easy to find that person!

I've had the same problem with mathematics my entire life.

Do you know how hard it is to draw a cube made of 8 cubes and measure 
all their sides? Do you know how long it takes to expand (x+y)^9 
manually, by hand? Do you have any idea how long it takes to figure out 
what the pattern is and where it's coming from?

...and then I discover some entry-level textbook that tells me how some 
dead guy already figured all this out several centuries ago. AND FOR 
ARBITRARY EXPONENTS!! >_<

Why do I bother?

Post a reply to this message

keep diluting/lying yourself, you're doing a great job, keep it up!

Post a reply to this message

Chambers wrote:
> Saul Luizaga wrote:
>>> No, you didn't even ask a question.
>>
>> news://news.povray.org:119/4a850da7@news.povray.org, check the last 
>> paragraph, proves you wrong. Did you liked to be corrected?
> 
> Yes, I do as a matter of fact.  I don't like being wrong.
> 
> ....Chambers
yeah, right.... hahaha

Post a reply to this message

Saul Luizaga wrote:
> keep diluting/lying yourself, you're doing a great job, keep it up!

That would be "deluding", not "diluting".  :-)

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

On Mon, 17 Aug 2009 09:27:31 -0700, Darren New <dne### [at] sanrrcom> wrote:

>Saul Luizaga wrote:
>> keep diluting/lying yourself, you're doing a great job, keep it up!
>
>That would be "deluding", not "diluting".  :-)

Like it makes any difference? Just show him where the fluoride lake is.
-- 

Regards
     Stephen

Post a reply to this message

Stephen wrote:
>> That would be "deluding", not "diluting".  :-)
> Like it makes any difference? 

Most speakers of english-as-a-second-language around here seem to appreciate 
learning the right words, is all.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message