[Gegl-developer] GPU support

[utkarsh shukla]

I am not at all sure that CUDA is an option at all or even OpenCL can be
used. They are a more higher level api based implementations tweeked for
computing. The thing for GEGL is quite a low level. You have to start from
the extreme basic and the best way to start is using GLSL (makes more sence
than HLSL or Cg). CUDA or OpenCL are all together different concepts and
they dont let the user see any shaders or other implementations. It can
easily be done using GLSL.

I applied for GSOC but had not got it but still I am very very interested it
this project particular. I just wish to take part in it and just wish if you
keep on posting on the mailing list.

On Sat, May 9, 2009 at 6:05 PM, Richard H. <forums at gimpusers.com> wrote:

> Hello,
>
> Thanks for your answer.
>
> >As far as I am concerned, CUDA and ATI's Stream SDK aren't an option
> >because they are video card specific.  I haven't really looked into
> >them but I'm sure they are easy to use for computations, but the same
> >computations can be accomplished through OpenGL through multiple
> >rendering/computation passes. Moreover, we decided to go with OpenGL
> >instead of a cross-platform API like OpenCL because implementations
> >for the latter are still either very young or non-existent for most
> >major platforms[1].
>
> Yes, I hope that all needed operations can be done via OpenGL, too because
> I
> have already experienced that CUDA sometimes makes problems even on
> supported
> platforms if you don't have exactly the same compiler options as the
> samples
> etc. On the other side, it's an additional unnecessary layer because the
> OpenGL computations use the same things you can directly access via CUDA or
> equivalent SDKs (if I have interpreted the infos I read about CUDA
> correctly).
> This layer is optimized for rendering and not for computing, so - from a
> pure
> simplicistic view - CUDA would be easier and more performant than OpenGL.
>
> I have never heard of OpenCL, but it seems to be very interesting (and not
> proprietary). I hope that it will be available for the most important
> platforms, soon.
>
> >Sorry, but I'm not really familiar with CUDA's threading model.
> Basically it's just the same as normal CPU threads, which would IMO be
> important to support, too. Many (especially Linux) systems don't have
> graphics
> acceleration available, but more than one CPU. Today you get already 8
> cores,
> i.e. filters would be ~8 times faster if they utilised all CPUs (for at
> least
> 8 available rectangles).
>
> >Furthermore, GEGL doesn't really take care of thread creation and
> >management.
>
> I have seen this. But isn't that bad? My opionion is that it should.
>
> > As far as I can see, your code's intent is to divide the
> >tasks into smaller packets of rectangle.  GEGL already has GEGL
> >processors that can be used to accomplish this[2]. In fact,
> >internally, GEGL uses tiles to divide the image into smaller packets
> >for on demand rendering and caching.
>
> Yes I have found the relevant code sections in the GEGL source (at least I
> think that I have ;) ), and they seem to have the linear structure I have
> mentioned in my first email. I mean that gegl_processor_work() returns a
> boolean telling you if there is some more work to do, in which case you
> have
> to call it again. I think this is not usable for parallelism, because you
> always have to wait until the current packet (processed by
> gegl_processor_work()) is finished until you know if you have to call it
> again. For parallelism, a better approach would be that gegl_process_work()
> does everything at once, for instance by moving the outer while loop over
> the
> rectangles into in inner for loop.
>
> I just wonder if that would help for the pure OpenGL approach, too. But I
> think that processing with OpenGL _and_ multithreading would make the best
> of
> pure OpenGL acceleration as well.
>
> I will have a look at the articles on gpgpu.org, too, seems to be a very
> interesting site, thanks.
>
> --
> Richard H. (via www.gimpusers.com)
> _______________________________________________
> Gegl-developer mailing list
> Gegl-developer at lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
>



-- 
Utkarsh Shukla,
Btech, Material Science and Metallurgy,
IIT KANPUR.
Mob: 9936339580
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /lists/gegl-developer/attachments/20090509/1b361dd3/attachment-0001.html