Re: [Gegl-developer] OpenCL support
Hi Victor, Thank you for clarifying, I was on the right track but didn't have a good example to compare against when using the gegl_buffer_get and gegl_buffer_set functions. I now have the desired results I need. As for the tiling, I understand the reasoning behind the need for such an architecture, but for the purposes of this tutorial it would be better to have the participants work on a whole contiguous chunk first, and let them understand the need for tiling as they advance and how they could perhaps optimize the tiling operations in GEGL for OpenCL. Once the tutorial is underway, and we have a better understanding of the operations, we can certainly discuss on such improvements for the OpenCL side. Thank you, And Best Regards, Adel From: victormath...@gmail.com Date: Mon, 19 Oct 2015 16:05:49 -0700 Subject: Re: [Gegl-developer] OpenCL support To: ade...@hotmail.com CC: gegl-developer-list@gnome.org Hi Adel, GEGL is a tiled engine and there's reasons for that, such as being able to manipulate large images that would use too much memory otherwise. Because of that, tiles are not contiguous in memory so there's no way of accessing this data without an extra copy. For that, you would use: - gegl_buffer_get (http://www.gegl.org/api.html#gegl_buffer_get) to copy the geglbuffer image data to a contiguous memory chunk of yours- do your processing- gegl_buffer_set to update the buffer with the new data Because that is an expensive copying operation we prefer that filters use the iterator unless global access to the image data is required in the filter. If you give a look at motion-blur-zoom.c, it does something like that (though it doesn't use CL). Hope that clears it up, let me know if you have any more questions.Victor On Tue, Oct 13, 2015 at 10:14 AM, Adel Johar wrote: Hi Victor, I’m currently trying to help Vincent out with the development of the tutorial, though I’ve hit a bit of a snag. Based on what I’ve seen from an old blog post of yours (and from code snippets from the current source codes), I understand that an iterator is used to iterate through the GEGL buffer to extract tiles and to run the OpenCL kernel on each tile. Do correct me if I’m wrong, but at this point it seems that an OpenCL kernel is called to operate on one tile at a time as the iterator moves the buffer from one tile to another. As part of the tutorial, rather than integrating the kernels directly into the GEGL library, I believe it would be more beneficial if those who partake in the tutorial to write their own host code as well. I was hoping to inquire on a more detailed explanation on how the image data can be extracted from the GEGL Buffer as a whole rather than as tiles through an iterator; whereby participants can then look at improving the tiling process and see how such improvements can be integrated into the GEGL library. While it would certainly be easier to integrate the kernels directly into the GEGL library, as a starting step it would be good if the users of the tutorial can learn both the kernel and host side of OpenCL. Thank you, And Best Regards, Adel ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] OpenCL support
Hi Adel, GEGL is a tiled engine and there's reasons for that, such as being able to manipulate large images that would use too much memory otherwise. Because of that, tiles are not contiguous in memory so there's no way of accessing this data without an extra copy. For that, you would use: - gegl_buffer_get (http://www.gegl.org/api.html#gegl_buffer_get) to copy the geglbuffer image data to a contiguous memory chunk of yours - do your processing - gegl_buffer_set to update the buffer with the new data Because that is an expensive copying operation we prefer that filters use the iterator unless global access to the image data is required in the filter. If you give a look at motion-blur-zoom.c, it does something like that (though it doesn't use CL). Hope that clears it up, let me know if you have any more questions. Victor On Tue, Oct 13, 2015 at 10:14 AM, Adel Johar wrote: > Hi Victor, > > > > I’m currently trying to help Vincent out with the development of the > tutorial, though I’ve hit a bit of a snag. Based on what I’ve seen from an > old blog post of yours (and from code snippets from the current source > codes), I understand that an iterator is used to iterate through the GEGL > buffer to extract tiles and to run the OpenCL kernel on each tile. Do > correct me if I’m wrong, but at this point it seems that an OpenCL kernel > is called to operate on one tile at a time as the iterator moves the buffer > from one tile to another. > > > > As part of the tutorial, rather than integrating the kernels directly into > the GEGL library, I believe it would be more beneficial if those who > partake in the tutorial to write their own host code as well. I was hoping > to inquire on a more detailed explanation on how the image data can be > extracted from the GEGL Buffer as a whole rather than as tiles through an > iterator; whereby participants can then look at improving the tiling > process and see how such improvements can be integrated into the GEGL > library. While it would certainly be easier to integrate the kernels > directly into the GEGL library, as a starting step it would be good if the > users of the tutorial can learn both the kernel and host side of OpenCL. > > > > Thank you, > > And Best Regards, > > Adel > > > > > ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] OpenCL support
Hi Victor, I’m currently trying to help Vincent out with the development of the tutorial, though I’ve hit a bit of a snag. Based on what I’ve seen from an old blog post of yours (and from code snippets from the current source codes), I understand that an iterator is used to iterate through the GEGL buffer to extract tiles and to run the OpenCL kernel on each tile. Do correct me if I’m wrong, but at this point it seems that an OpenCL kernel is called to operate on one tile at a time as the iterator moves the buffer from one tile to another. As part of the tutorial, rather than integrating the kernels directly into the GEGL library, I believe it would be more beneficial if those who partake in the tutorial to write their own host code as well. I was hoping to inquire on a more detailed explanation on how the image data can be extracted from the GEGL Buffer as a whole rather than as tiles through an iterator; whereby participants can then look at improving the tiling process and see how such improvements can be integrated into the GEGL library. While it would certainly be easier to integrate the kernels directly into the GEGL library, as a starting step it would be good if the users of the tutorial can learn both the kernel and host side of OpenCL. Thank you, And Best Regards, Adel ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] OpenCL support
Hi Victor,
(after 2 crashes of mail programs and browsers, I hope this time I will be
able to send this mail)
There is no need to check all patches - let me explain. The project
consists of two parts: the front-runners (learning in a group) and the rest
(people learning from the group). The front-runners will pick a filter,
then all are going to port it to OpenCL - each version will be discussed
with the group and tested on the machines. By combining all that has been
learned, the kernel with the best results will result in a single patch. We
mostly need your help with the first few patches. People who find
improvements after the first path, first have to do a list of checks before
sending a patch.
The people who have done the class successfully, can focus on the harder
problems you wrote down. When we get to that point, what I ask from you is
to make the descriptions of the 4 points.
StreamComputing will help out too, if time permits - our first focus is to
guide the front-runners. We might be most useful in benchmarking the
various kernels on our own servers - what build-system do you use, by the
way? Buildbot.net?
Yes, if you agree that I setup this OpenCL-learning-project for GEGL, a
tutorial would be the best help to get people started. I saw the API is
quite useful and can be used to create a small program that reads an image
and kernel, and writes an image, checks error-level and shows the time the
kernel took. Later interactive mode can be added, or to benchmark on a
directory of images.
Yes, I've checked a few filters. Will be good examples. We do need to
profile&benchmark them, to see if they can be made faster before people use
it to learn.
Cheers,
Vincent
On 31 July 2015 at 20:18, Victor Oliveira wrote:
> Hi Vincent! Welcome to the GEGL list.
>
> You can refer to http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL
> for the list of filters in GIMP and GEGL that have been ported.
>
> Being honest I don't think there's enough people here with OpenCL
> background to review that many patches! So, a great way of helping out with
> the OpenCL support is to get involved with the community, build knowledge
> of the GEGL codebase and help out not only with the OpenCL bits but also
> infrastructure work. We've had people come and go that implement filters
> but as important as that is to keep engaged and be sure it keeps working.
>
> So, personally, what I think it's the best way to get OpenCL out there for
> users which I'd do myself if I had the time {in order of importance}:
>
> 1) Verify that currently implemented filters produce correct results and
> are faster than CPU. We are in need of a systematic verification of
> correctness of all filters, with different test images cases.
> 2) Stress test of the GPU code. What happens if you open another
> application that steals our GPU memory?
> 3) GPU profiling at application-level? Are we doing something stupid so
> that there's bubbles in our GPU pipeline?
> 4) Work with the GIMP team to minimize the tilling issue.
>
> As I said, unfortunately I don't have the time to actually code new stuff
> but I'd extremely interested in helping out to have a simple tutorial that
> could bring new people to the project, what you have in mind?
>
> By the way, have you given a look at this for an example of pixelwise
> filter?
>
>
> https://git.gnome.org/browse/gegl/tree/operations/common/brightness-contrast.c
> https://git.gnome.org/browse/gegl/tree/opencl/brightness-contrast.cl
>
> We can keep discussing here ideas.
>
> Regards,
> Victor
>
> On Thu, Jul 30, 2015 at 12:40 PM, Vincent Hindriksen <
> vinc...@streamcomputing.eu> wrote:
>
>> Hi,
>>
>> You might assume I will ask about the current state of OpenCL, but my
>> question is different. I want to help to get OpenCL support get done.
>>
>> In short I want a group of beginners try to implement the same filter in
>> OpenCL, learning together. There will be support for them, so eventually
>> they create a correct and fast kernel. And yes, there is serious demand for
>> this. All I need from you is to help me develop a tutorial to get from zero
>> to the first kernel, while learning the basics of OpenCL. I think that we
>> can do a filter per week, while improvements will keep coming because of a
>> high-score list.
>>
>> Is there somebody I can talk to about this? Or can we discuss it here?
>>
>> Kind regards,
>> Vincent
>>
>> ___
>> gegl-developer-list mailing list
>> List address:gegl-developer-list@gnome.org
>> List membership:
>> https://mail.gnome.org/mailman/listinfo/gegl-developer-list
>>
>>
>>
>
--
--
___
V.G.Hindriksen MSc., CEO
StreamComputing BV - http://www.streamcomputing.eu
Location: Amsterdam, Netherlands, Europe
Cell: +31 6 45400456
NEW PHONE NUMBER: +31 854865760
KvK-number (Chamber of Commerce): 61901873
Rabo Bank (IBAN/SEPA): NL89RABO0113885571 - BIC: RABONL2U
OpenCL
Re: [Gegl-developer] OpenCL support
Hi Vincent! Welcome to the GEGL list.
You can refer to http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL
for the list of filters in GIMP and GEGL that have been ported.
Being honest I don't think there's enough people here with OpenCL
background to review that many patches! So, a great way of helping out with
the OpenCL support is to get involved with the community, build knowledge
of the GEGL codebase and help out not only with the OpenCL bits but also
infrastructure work. We've had people come and go that implement filters
but as important as that is to keep engaged and be sure it keeps working.
So, personally, what I think it's the best way to get OpenCL out there for
users which I'd do myself if I had the time {in order of importance}:
1) Verify that currently implemented filters produce correct results and
are faster than CPU. We are in need of a systematic verification of
correctness of all filters, with different test images cases.
2) Stress test of the GPU code. What happens if you open another
application that steals our GPU memory?
3) GPU profiling at application-level? Are we doing something stupid so
that there's bubbles in our GPU pipeline?
4) Work with the GIMP team to minimize the tilling issue.
As I said, unfortunately I don't have the time to actually code new stuff
but I'd extremely interested in helping out to have a simple tutorial that
could bring new people to the project, what you have in mind?
By the way, have you given a look at this for an example of pixelwise
filter?
https://git.gnome.org/browse/gegl/tree/operations/common/brightness-contrast.c
https://git.gnome.org/browse/gegl/tree/opencl/brightness-contrast.cl
We can keep discussing here ideas.
Regards,
Victor
On Thu, Jul 30, 2015 at 12:40 PM, Vincent Hindriksen <
vinc...@streamcomputing.eu> wrote:
> Hi,
>
> You might assume I will ask about the current state of OpenCL, but my
> question is different. I want to help to get OpenCL support get done.
>
> In short I want a group of beginners try to implement the same filter in
> OpenCL, learning together. There will be support for them, so eventually
> they create a correct and fast kernel. And yes, there is serious demand for
> this. All I need from you is to help me develop a tutorial to get from zero
> to the first kernel, while learning the basics of OpenCL. I think that we
> can do a filter per week, while improvements will keep coming because of a
> high-score list.
>
> Is there somebody I can talk to about this? Or can we discuss it here?
>
> Kind regards,
> Vincent
>
> ___
> gegl-developer-list mailing list
> List address:gegl-developer-list@gnome.org
> List membership:
> https://mail.gnome.org/mailman/listinfo/gegl-developer-list
>
>
>
___
gegl-developer-list mailing list
List address:gegl-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] OpenCL support in GEGL is almost there
On Tue, Apr 10, 2012 at 11:12 PM, johannes hanika wrote: > actually darktable's pixel pipeline was based on gegl as the project > started (you'll still notice some #ifdef HAVE_GEGL if you look around > the code closely). that was 2-3 years ago and at that time it turned > out a simple DIY pipeline was a lot faster, to a point where it just > didn't seem practicable to use gegl. that said i love the clean gegl > api and would totally love to see dt/gimp use the same rendering api > and have some compatible interchange format. It is not surprising that doing a DIY pipeline would give faster results more immediately, for the first few years after I took up maintainership of the then derelict GEGL project my previous graph based full image compositor gggl continued to run circles around GEGL but slowly as GEGL matured it has gotten better - your concerns are due to things that are not completed - contributions are as always most welcome (note that for features like demosaicing GEGL has very naive support currently; and even if someone wanted to port for instance more advanced/alternative demosaicing from Darktable - they would not be able to since GEGL is LGPL). > i guess the biggest issues back then were: > > - processing the image as a whole, not just the region of interest at > the currently visible scale. darktable pre-downsamples and processes > only these pixels (comes with issues, mostly works fine). > > - i had the feeling that even resampling the image to these small > tiles came with a huge overhead Doing it with a scale node would be slow, using the built in mechanisms to generate mip-maps in GeglBuffer would fast. The plan for GEGL has been to do previews rendering of the current visible scale directly on these mip-map levels; contributions in that area would be most welcome. The support is not complete but hopefully most of the API changes neccesary landed in GEGL 0.2.0 which GIMP-2.8 depends on. GIMP will not be able to make use of such snappier compositing and preview using GEGL until close to the end of the 2.10 cycle when all drawables are native GeglBuffers. > - easy to insert a cache (we cache the input to the plugin the user is > currently tweaking for example). GEGL has had caches in the pipeline; some automatic as well as the ability to forcibly opt in and out of caching. > - we have esoteric pixel formats (bayer patterns, in 16-bit and in > 32-bit float, etc.). GEGL supports any pixel format supported by babl, this includes 16bit and 32bit integer as well as floating point. Demosaicing such bayer patterns is also well within the scope of GEGL. In the end doing a single chained pipeline processor with GEGL should not be much code and it should end up being fast. It is just taking longer to get there because GIMP has been slow in it's own adoption of GEGL and it seems like most projects prefer to put together the simplest thing that possibly can work and grow their own custom solution from that instead of adopting and helping out with a common infrastructure. With the recent goat-invasion of GIMP the future for GEGL is brightening up and I have hopes that GEGLs momentum and adoption will finally be increasing and hopefully be able to sustain itself also without me pushing it. /Ø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-list mailing list gegl-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] OpenCL support in GEGL is almost there
hey! good news, and congrats on putting it into gimp. actually darktable's pixel pipeline was based on gegl as the project started (you'll still notice some #ifdef HAVE_GEGL if you look around the code closely). that was 2-3 years ago and at that time it turned out a simple DIY pipeline was a lot faster, to a point where it just didn't seem practicable to use gegl. that said i love the clean gegl api and would totally love to see dt/gimp use the same rendering api and have some compatible interchange format. i guess the biggest issues back then were: - processing the image as a whole, not just the region of interest at the currently visible scale. darktable pre-downsamples and processes only these pixels (comes with issues, mostly works fine). - i had the feeling that even resampling the image to these small tiles came with a huge overhead - we have plugins that need filter radii of 128px or more. so tiled processing is hard to make fast. these are some crucial features for us: - needs to be fast (1Mpix < 100ms if possible, our equalizer is on the limit). that's because we always process the whole pipe potentially, might be 20 active plugins and you want interactive feedback. - easy to insert a cache (we cache the input to the plugin the user is currently tweaking for example). - i mentioned the large filter radius overlap thing before. mostly for bilateral filtering (reasonable filter size might be ~30% of the image width) and the edge aware wavelets. - we have esoteric pixel formats (bayer patterns, in 16-bit and in 32-bit float, etc.). - we have huge problems with memory usage. also our opencl support is great, fast, stable, and doesn't need to be there compile-time. which makes it easy for users to fall back to the cpu code path, which in practice happens for every system or driver update.. so i guess i'm saying the cpu codepath is very important to us, too, and we spend some considerable time optimizing it (threading/sse and such). cheers, jo On Wed, Apr 11, 2012 at 6:04 AM, Victor Oliveira wrote: > Hello everyone, > > I'm a GEGL developer and I've been working since last year implementing > OpenCL support in GEGL. We have for now: > > - An API to write OpenCL point and area operations > - A way to share image data between operations in the GPU (so we don't have > to bring the image back and forth the CPU for each operator) > - +20 GEGL operations have OpenCL support already > - It's fast > - It's been included in GIMP 2.8RC1 > > Darktable has its own OpenCL support code (which is pretty good, by the > way). I'd like to start talks to avoid work repetition in both programs and > to make an argument pro-GEGL use in Darktable :) > > bye! > Victor Oliveira > > ___ > gegl-developer-list mailing list > gegl-developer-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gegl-developer-list > ___ gegl-developer-list mailing list gegl-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gegl-developer-list
