On Sun, Mar 27, 2011 at 8:08 PM, Victor Oliveira
> Hello everyone. My name is Victor Oliveira. I'm a master's student at
> the School of Electrical and Computer Engineering - University of
> Campinas, Brazil.
> I work with Image Processing and Machine Learning and I've been using
> GPUs (CUDA) in my work since 2009. More recently, we've migrated our
> projects to OpenCL, which has given me more experience with GPU
> programming. I have a strong background in C/C++ and Python.
> Also, I've been using GEGL for some time in my projects. I noticed a
> while ago that there is a branch
> [http://git.gnome.org/browse/gegl/tree?h=gsoc2009-gpu] that wasn't
> merged in GEGL's main tree.
> If I understood it correctly, this specific branch is able to do
> pixelwise operations using OpenGL shaders and automatic memory
> management beetween the cpu and gpu. My idea is to use this memory
> management scheme to allow gegl operations with OpenCL. I've already
> presented this idea in #gegl without further details and I'd like to
> discuss it here.
If moving to OpenCL, (and if OpenCL needs separately managed memory;
which I think it does) basing it on the existing unmerged GPU branch
would be the best plan moving forward. The general gist of the work
that was done in the previous gsoc was to extend GeglBuffer with the
ability to have a separate, internal backend/cache of gpu side tiles,
that have their own revision; when tiles are requested either on the
gpu or cpu side, migration is done automatically to ensure that the
newest version is used.
This management scheme was succesfully implemented for GLSL based
shaders and proof of concept implementations of some point operations
were done. Repeating the things that were done in this gsoc for OpenCL
should not take as long as it did for the original GPU branch since a
lot of the issues would already be solved. If core color correction,
compositing ops and gaussian blur have vfuncs for GPU side processing;
many simpler compositions would be possible to do fully on the GPU -
while compositions with some cpu based ops would do the migration back
and forth as needed (with incurred performance impact).
Another important issue when implementing a new set of vfunc for the
OpenCL code (which would have to be fully conditional at compile time,
to keep GEGL buildable without).
One thing that could be interesting to do is to make it possible to
turn on a runtime flag that tests the OpenCL paths against the cpu
paths when running GEGLs test suite, thus ensuring that the results
are really interchangeable.
> The first step would be adapting the existing code and re-implementing
> the pixelwise operations in OpenCL. Meanwhile, we have to remember
> that OpenCL can be compiled to run in the cpu also, so we don't need
> to make memory transfers in this case.
I do not know enough details about OpenCL and its data buffers to
asses how this best would be done. Though it would be interesting to
see how the code generated compares with the existing cpu code; if
fully free software toolchains for OpenCL (perhaps using LLVM)
emerges, it could be interesting to use OpenCL as the officially
encouraged way of implementing GEGL ops.
/Øyvind K - GEGL maintainer
«The future is already here. It's just not very evenly distributed»
-- William Gibson
Gimp-developer mailing list