I would just like to chime in on this proposal with my personal experience developing in OpenCL for use in the Blender Game Engine. As has been pointed out, not everything can be sped up with OpenCL, and because it supports multiple device architectures, a code optimized for the GPU won't run fast on the CPU. Then there is the question of user's having the hardware to even run it, necessitating a CPU only fall-back. With all these factors one might ask, is it worth it? I personally think it is very well worth it, especially if it is viewed as an optional accelerator rather than wholesale algorithm replacement. The speed benefits for the highly parallelizable problems already mentioned such as compositing/filters as well as physics such as particle systems (plug: http://enja.org/2010/12/16/particles-in-bge-fluids-in-real-time-with-opencl/ ) are very convincing. There is a lot of research going into GPU computing for CG applications, and NVIDIA is pushing CUDA hard. While Blender won't adopt a proprietary solution such as CUDA, many of the algorithms and techniques developed for it can be translated to OpenCL.
I'm excited about this proposal not because I want faster compositing, but because it sets up a framework for dealing with OpenCL in a sane way inside Blender. I'm currently developing my library standalone and linking it to Blender, using my own OpenCL wrappers around the Khronos ones. As I learn more about the Blender codebase, as well as look to Bullet I am dismayed by my own code's fragility. Sure it runs fast on the machines I've tested but I do not trust it to be in a consumer facing application for a while. As a student and a researcher I'm compelled to spend most of my time developing the algorithm and as much as I'd like to integrate my code cleanly it will be a while before that can happen. This proposal would give me as a developer a better platform for contributing directly to Blender, as well as a central location for me to put any effort into standardizing an OpenCL interface based on my experience with it. Furthermore, as other developers start to accelerate their code we will need a solid way of managing device resources and avoid redundant or competing memory transfers. With the new architectures coming out, the prevalence of capable GPUs and the increasingly sophisticated algorithms available I think OpenCL is going to be essential. I'd like to throw what little weight I have behind this proposal along with my 2 cents :) Ian Hi all, The last few months I have worked hard on a the proposal of the OpenCL based compositor. Currently the proposal is ready that it is clear how the solution should work and what the impact is. As the proposal is on the technical level the end-user won't feel a difference, except for a fast tile based compositor system. In functionality it should be the same. There are 2 aspects that will be solved: * Tiled based compositing * OpenCL compositing To implement these I will introduce additional components: * Tiled based memory manager * Node (pre-)compiler * Configurable automatically data conversion for compositor node systems * OpenCL driver manager * OpenCL configuration screen * Some debug information: * OpenCL program, performance etc. * Execution tree (including data types, resolution and kernelgrouping) * Visualizing tiles needed for calculation of an area. And introduce several new data types * Kernels and KernelGroup * Camera data type * Various color data types I have put all the documents on a project-website for review. As the proposal is quite long and complex. (all decisions are connected with each other.) Please use bf-committers or #blendercoders to discuss the proposal also if something is not clear. http://ocl.atmind.nl/doku.php?id=design:proposal:compositor-redesign Cheers, Jeroen Bakker -- Ian Johnson http://enja.org _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers