On Wed, Apr 1, 2009 at 7:00 PM, Jerson Michael Perpetua
<jersonperpetua@xxxxxxxxx> 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.
--
«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
