[Bf-committers] Proposal: Blender OpenCL compositor

[Brecht Van Lommel]

Hi Jeroen,

Node compiler. I really dislike code going through a node compiler.
OpenCL is basically C with some restrictions and a few extra
qualifiers, let's take advantage of that and for the CPU just compile
as part of the regular compilation process. It's not clear to me why
this node compiler is necessary. What I would propose is to just
#include the kernel into the CMP_*, and call it directly from there.
There's a few things to do to make that work, but still seems simpler
than having a makenodes inbetween.

Automatic data conversion between nodes. What I'm not sure about is
the different color data types (RGBA, HSVA, YUVA, ..). This would no
be exposed to the user, all they would know is that it's a Color,
right? Is it really necessary to have these as core data types, can't
the nodes do such conversions if they want to?

Kernel types. To me it seems perhaps better to not classify kernel
types this way, but to classify buffer inputs as either random access
or not. I'm not sure about how you planned to do kernel grouping, but
thinking of it this way also makes it possible to group two blurs that
are then mixed together for example.

Memory buffers states. Not clear to me why these states are stored as
part of the buffer itself, seems to me some of these are more related
to the node execution, not the memory manager.

Consistency between GPU and CPU. New CUDA GPU's can actually do
identical floating points ops, if you're careful. If you use
optimizations like fast math, SSE, fused mutliply-add, this becomes
harder. My guess is that differences will nearly all the time be too
small to be visible regardless, since colors don't need that many bits
of precision.

Another problem may be that some types of optimizations run well on
the CPU but are harder on the GPU. Would it still be possible to have
such CPU optimized implementations, or would everything have to be
done in kernels?

Brecht.