Bullet uses its own MiniCL fallback, it requires no external references, the 
main issue is that it is not a full OpenCL implementation (no barriers yet 
etc). We developed MiniCL primarily for debugging and secondary to run the 
Bullet OpenCL kernels on platforms that lack an OpenCL implementation.

The Intel and AMD OpenCL drivers for CPU perform similar to regular multi 
threaded code (pthreads, openpm etc) but it is more suitable for data parallel 
problems and not for complex code with many branches.

So while you can port a compositor or cloth simulation to OpenCL, most general 
purpose code requires large refactoring and simplification causing reduced 
quality, so don't expect miracles.

Still, it will be fun to see compositing, physics simulation etc in Blender 
being accelerated through OpenCL, optionally.

Thanks,
Erwin

On Jan 16, 2011, at 5:34 AM, Jeroen Bakker <[email protected]> wrote:

> On 01/15/2011 03:55 PM, (Ry)akiotakis (An)tonis wrote:
>> On 15 January 2011 09:19, Matt Ebb<[email protected]>  wrote:
>>> While I can believe that there will be dedicated online farms set up
>>> for this sort of thing I was more referring to farms in animation
>>> studios, most of which are not designed around GPU power - now, and
>>> nor probably for a while in the future. Even imagining if in the
>>> future blender uses openCL heavily, if a studio has not designed a
>>> farm specifically for blender (which is quite rare), CPU performance
>>> will continue to be very important. I'm curious how openCL translates
>>> to CPU multiprocessing performance, especially in comparison with
>>> using something like blender's existing pthread wrapper.
>>> 
>>> cheers,
>>> 
>>> Matt
>>> _______________________________________________
>>> Bf-committers mailing list
>>> [email protected]
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> 
>> I have to disagree on that. Almost every 'serious' user today has an
>> OpenCL capable GPU and they can benefit from an OpenCL implementation.
>> Besides OpenCL allows for utilization of both CPU and GPU at the same
>> time. It's not as if it sets a restriction on CPUs.
> In my understanding the issue is that internal renderfarms have no 
> 'OpenCL' capable GPU (yet). It is not an issue on the user side. Like 
> during durian, we have workstations with medium gpu's and only cpu based 
> renderfarm. The question is how would a cpu-based renderfarm benefit 
> from opencl?
> 
> Users on the otherhand have different issues. Our user population also 
> have non OpenCL capable hardware/OS's. therefore we still need a full 
> CPU-based fallback or the bulletsolution by implementing an own opencl 
> driver. The bullet solution is complicated in our situation as it needs 
> a lot of external references (compilers, linkers, loaders etc)
> 
> Jeroen
> _______________________________________________
> Bf-committers mailing list
> [email protected]
> http://lists.blender.org/mailman/listinfo/bf-committers
_______________________________________________
Bf-committers mailing list
[email protected]
http://lists.blender.org/mailman/listinfo/bf-committers

Reply via email to