|
 |
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
|
 |