[Bf-committers] Proposal: Blender OpenCL compositor

[Ian Johnson]

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