POV-Ray : Newsgroups : povray.off-topic : Suggestion: OpenCL : Re: Suggestion: OpenCL Server Time
5 Sep 2024 09:26:47 EDT (-0400)
  Re: Suggestion: OpenCL  
From: Saul Luizaga
Date: 14 Aug 2009 03:09:27
Message: <4a850da7@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.