On Tue, Mar 29, 2011 at 2:36 PM, Øyvind Kolås <pippin@xxxxxxxx> wrote: > 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. > 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 migrations. >> 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 Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
