On Tue, Mar 29, 2011 at 2:36 PM, Øyvind Kolås <pip...@gimp.org> wrote:
> On Sun, Mar 27, 2011 at 8:08 PM, Victor Oliveira
> <victormath...@gmail.com> wrote:
>> 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.

Maybe we can also use this to benchmark plug-ins and see if the
speedup of using OpenCL is greater than the overhead during buffer

>> 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.

This is a nice topic. A (sufficient smart :) compiler probably is able
to generate optimized code for OpenCL in an easier way than C. OpenCL
language is naturally data-parallel, which allows vector instructions,
for example.

So what are the next steps then? Do i have to write a more formal proposal?

> /Øyvind K - GEGL maintainer
> --
> «The future is already here. It's just not very evenly distributed»
>                                                  -- William Gibson
> http://pippin.gimp.org/                            http://ffii.org/
Gimp-developer mailing list

Reply via email to