GSoC 2009: OpenGL GPU resampling in GEGL (an update)
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 2009: OpenGL GPU resampling in GEGL (an update) | Jerson Michael Perpetua | 01 Apr 20:00 |
| GSoC 2009: OpenGL GPU resampling in GEGL (an update) | Øyvind Kolås | 02 Apr 00:14 |
| GSoC 2009: OpenGL GPU resampling in GEGL (an update) | Jerson Michael Perpetua | 03 Apr 02:54 |
GSoC 2009: OpenGL GPU resampling in GEGL (an update)
Hello everyone,
I have already corresponded with Nicolas (thanks) and was able to fix a general overview of what I should do to implement OpenGL GPU resampling in GEGL or something similar. The following is my general plan of action for this topic:
(1) Extend the current GeglBuffer implementation to store a copy of "some" image sub-buffers/mipmaps in volatile GPU memory (textures, VBOs). The image data in the GPU memory will be potentially accelerated as they are already cached in the GPU as opposed to the ones that are stored in primary memory.
(2) Implement some resamplers using pixel shaders that operate on cached image data on the GPU memory. I might as well start with the suggested hardware bilinear sampler to get a feel with how to integrate shaders with GEGL and proceed to more complicated resamplers (nohalo, snohalo, etc.).
The above-mentioned plan is a huge simplification. I will come back with more details as I dig through OpenGL, GPGPU and GEGL's internals. Also, if you have anything to say, please feel free to react. I am still learning the intricacies of OpenGL and GEGL and would very much appreciate your input.
Furthermore, Nicolas expressed that instead of resamplers, I could implement other things. I elected that that "other thing" could be GeglOperations. Some GeglOperations could be accelerated through shaders. So instead of doing point no. 2 above, I could implement one or two GeglOperations through shaders instead. GEGL gurus, do you think this is at all feasible? Am I misunderstanding anything?
Kind regards,
Daerd
jersonperpetua at gmail dot com
GSoC 2009: OpenGL GPU resampling in GEGL (an update)
On Wed, Apr 1, 2009 at 7:00 PM, Jerson Michael Perpetua wrote:
(1) Extend the current GeglBuffer implementation to store a copy of "some" image sub-buffers/mipmaps in volatile GPU memory (textures, VBOs). The image data in the GPU memory will be potentially accelerated as they are already cached in the GPU as opposed to the ones that are stored in primary memory.
snip<
Furthermore, Nicolas expressed that instead of resamplers, I could implement other things. I elected that that "other thing" could be GeglOperations. Some GeglOperations could be accelerated through shaders. So instead of doing point no. 2 above, I could implement one or two GeglOperations through shaders instead. GEGL gurus, do you think this is at all feasible? Am I misunderstanding anything?
Implementing the framework for letting GEGL do processing on the GPU is an interesting topic. Last year GeglBuffer hadn't matured enough to advise someone to start the task; now it is. Here is a plan containing my thoughts on what is needs to be done from a GEGL perspective.
GPU based GeglOperations would be needed to implement and test GPU based resamplers for GEGL. Doing only one GeglOperation in a graph on the GPU will most likely be slower than doing all operations on the CPU; we need multiple operations to offset the performance cost of the CPU->GPU GPU->CPU transfers. Hopefully it is feasible to use shaders on tiles (or compose and split up larger buffers on the GPU), this would make it possible to keep track of where the valid tiles for a GeglBuffer reside; CPU or GPU side (using two revision counts). I hope this would make us able to use the same GeglBuffer handle for both CPU and GPU access in the same process minimizing the changes needed to the rest of GEGL.
The type of GeglOperation that is most important to get going is GeglOperationPointComposer operations or as a starting point the op gegl:over which is the normal layer mode in GIMP, all other such ops behave the same with regards to input and output buffers but use a different formula.
GeglOperationPointFilter is even simpler and would accommodate for the needs of operations like brightness contrast, desaturation and more. None of these would be using resamplers but they are the bulk of operations that needs to be performed.
The operations that are likely to need a resampler (GPU built in or custom) are the more complex ones that can have varying input and output buffer sizes. The most needed one is the transformation class of operations. (Currently only affine transformations are in GEGL, but we need perspective as well to avoid a feature regression from GIMP which does this.)
/Øyvind K.
GSoC 2009: OpenGL GPU resampling in GEGL (an update)
Thank you for the feedback Øyvind. I think that, at this point, I should probably narrow my topic down to adding GPU-support for GeglBuffer and two of the GEGL classes you've mentioned above. I will delegate implementation of the GPU-support for resamplers as optional for this year's GSoC.
However, as I have noted in my introduction, my primary motivation for joining GSoC is to kick-start my way to being a regular Gimp contributor. After GSoC, I will most probably continue to work on adding GPU-support for GEGL as well as contribute to Gimp's greater improvement.
I've thought of "OpenGL GPU-support for GEGL" as my new topic name but I'm open to more precise suggestions. :-)
Moreover, dear Gimp developers, I'm also interested in "Improved Foreground Selection Tool" as another topic proposal. I know that another prospected GSoC student has expressed interest in this topic, but competition is supposed to be good, right? ;-) I'd also appreciate to hear your thoughts regarding this last matter.
Daerd
