Alan,
You're code certainly sounds very useful, and I would love to see it open sourced. May I suggest, as was already stated, that you decide upon a license, find a name for your library, and then open a github (http://github.com) account (or any other free hosting) where you upload the code. Whether it will be made part of gimp or not is a different issue, and I agree that you should introducing closed source dependencies for such a project is not a good idea.
Btw, there is an open standard for CUDA-like operations being developed, called OpenCL, but it is not very supported yet. See: http://en.wikipedia.org/wiki/OpenCL . Pehaps you want to investigate whether there is NVIDIA support for the operations that you use, and if so, recode the algorithms in OpenCL? But again, I would do the work in a separate repository in github.
Regards,
Dov
You're code certainly sounds very useful, and I would love to see it open sourced. May I suggest, as was already stated, that you decide upon a license, find a name for your library, and then open a github (http://github.com) account (or any other free hosting) where you upload the code. Whether it will be made part of gimp or not is a different issue, and I agree that you should introducing closed source dependencies for such a project is not a good idea.
Btw, there is an open standard for CUDA-like operations being developed, called OpenCL, but it is not very supported yet. See: http://en.wikipedia.org/wiki/OpenCL . Pehaps you want to investigate whether there is NVIDIA support for the operations that you use, and if so, recode the algorithms in OpenCL? But again, I would do the work in a separate repository in github.
Regards,
Dov
On Mon, Aug 30, 2010 at 01:46, Øyvind Kolås <pippin@xxxxxxxx> wrote:
On Sun, Aug 29, 2010 at 11:40 PM, Alan Reiner <etotheipi@xxxxxxxxx> wrote:Doing image processing on the GPU using OpenGL and GLSL for GIMPs next
> I forgot that CUDA is not OSS. We don't have to worry about that because we
> only use it for in-house simulations. I only remembered it was free for
> such use.
>
> I know that similar stuff can be done with OpenGL, but that's a completely
> different beast. There's also OpenCL but I don't know anything about that
> either. At least those two solutions should work on both NVIDIA and ATI,
> but I believe the code still needs to be tailored specifically for each
> architecture.
>
> As for portability, I don't see that as a concern for any of these. For
> various platforms, it would be preprocessed out. For everything else it can
> detect and disable itself if it won't work on the resident card.
>
> I might look a little bit into the OpenGL solution to see if that's
> feasible, but my understanding is that it's more archaic and not as
> powerful. And I personally don't have a reason to learn it. Perhaps one
> day when I have time to contribute directly to an OSS project.
generation engine is planned and the initial proof of concept of such
a system deeply integrated with GEGL exist in a branch of the git
repository at http://git.gnome.org/browse/gegl/log/?h=gsoc2009-gpu ,
The approach taken there is to implement automatic migration of tiles
between cpu and gpu.
/Øyvind K.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
