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 


> 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