GSOC 2011 - GEGL: Make OpenGL branch use OpenCL
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| GSOC 2011 - GEGL: Make OpenGL branch use OpenCL | victormatheus@gmail.com | 24 Mar 19:35 |
| GSOC 2011 - GEGL: Make OpenGL branch use OpenCL | " | 29 Mar 17:36 |
| GSOC 2011 - GEGL: Make OpenGL branch use OpenCL | Victor Oliveira | 29 Mar 18:24 |
| GSOC 2011 - GEGL: Make OpenGL branch use OpenCL | Alexandre Prokoudine | 29 Mar 21:33 |
| GSOC 2011 - GEGL: Make OpenGL branch use OpenCL | johannes hanika | 29 Mar 21:44 |
| GSOC 2011 - GEGL: Make OpenGL branch use OpenCL | Victor Oliveira | 30 Mar 00:03 |
GSOC 2011 - GEGL: Make OpenGL branch use OpenCL
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.
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.
After this, we can make more complex operations, like convolutions, color corrections, etc. I think the objective is to do as many operations as possible in the gpu, in order to avoid costly memory transfers using PCIe (although some new architectures like Fusion share the same memory space).
So, what do you think about this project? I'd like to receive as many suggestions as possible :)
Also, if you guys think this project isn't a good idea, I'm willing to port GIMP plugins to GEGL operations. Let's see what happens here :)
GSOC 2011 - GEGL: Make OpenGL branch use OpenCL
On Sun, Mar 27, 2011 at 8:08 PM, Victor Oliveira 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/ _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
GSOC 2011 - GEGL: Make OpenGL branch use OpenCL
On Tue, Mar 29, 2011 at 2:36 PM, Øyvind Kolås wrote:
On Sun, Mar 27, 2011 at 8:08 PM, Victor Oliveira 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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
GSOC 2011 - GEGL: Make OpenGL branch use OpenCL
On 3/29/11, Øyvind Kolås wrote:
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).
As much as I like OpenCL, this part of implementation is going to be hairy, because to build an app that uses OpenCL one needs binary ATi drivers, binary NVidia drivers or Gallium 3D. Or you would have to keep a local copy of respective headers (or write your own ones). You can imagine the kind of fun that packagers will have.
Alexandre Prokoudine http://libregraphicsworld.org
Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
GSOC 2011 - GEGL: Make OpenGL branch use OpenCL
On Wed, Mar 30, 2011 at 10:33 AM, Alexandre Prokoudine wrote:
On 3/29/11, Øyvind Kolås wrote:
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).
As much as I like OpenCL, this part of implementation is going to be hairy, because to build an app that uses OpenCL one needs binary ATi drivers, binary NVidia drivers or Gallium 3D. Or you would have to keep a local copy of respective headers (or write your own ones). You can imagine the kind of fun that packagers will have.
but that's really a packaging problem. it is perfectly possible to implement stub functions that encapsulate the opencl stuff and all conditional code, so most of the code can be kept clean of preprocessor magic. see
maybe it would even be possible to dlopen() the cl dependencies during runtime?
cheers, jo
Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
GSOC 2011 - GEGL: Make OpenGL branch use OpenCL
Hi! This is a question I haven't though.
Well, I think your second option is feasible. OpenCL headers are
freely (as in freedom) distributed in the khronos group page
(http://www.khronos.org/registry/cl/). We just have to hope vendors
follow this specification.
Of course, we still need proprietary drivers (libOpenCL.so) in the
runtime until there is an open-source implementation. But I don't know
if this is a problem.
bye!
On Tue, Mar 29, 2011 at 6:33 PM, Alexandre Prokoudine wrote:
On 3/29/11, Øyvind Kolås wrote:
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).
As much as I like OpenCL, this part of implementation is going to be hairy, because to build an app that uses OpenCL one needs binary ATi drivers, binary NVidia drivers or Gallium 3D. Or you would have to keep a local copy of respective headers (or write your own ones). You can imagine the kind of fun that packagers will have.
Alexandre Prokoudine http://libregraphicsworld.org
_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
