On Sun, Mar 27, 2011 at 8:08 PM, Victor Oliveira <victormatheus@xxxxxxxxx> 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. > 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 http://pippin.gimp.org/ ; http://ffii.org/ _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
