RSS/Atom feed Twitter
Site is read-only, email is disabled

GSoC 2009: OpenGL GPU resampling in GEGL (an update)

This discussion is connected to the gegl-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.

1 of 2 messages available
Toggle history

Please log in to manage your subscriptions.

6a95403a0904011100u26ac7c86... 07 Oct 20:29
  GSoC 2009: OpenGL GPU resampling in GEGL (an update) Øyvind Kolås 02 Apr 00:14
Øyvind Kolås
2009-04-02 00:14:59 UTC (over 15 years ago)

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.