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