[PATCH 1/1] video-degradation: Don't crash when CL build fails
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.
[PATCH 1/1] video-degradation: Don't crash when CL build fails | Jan Vesely | 14 May 23:04 |
[PATCH 1/1] video-degradation: Don't crash when CL build fails | Øyvind Kolås | 15 May 12:12 |
[PATCH 1/1] video-degradation: Don't crash when CL build fails | Jan Vesely | 15 May 20:03 |
[PATCH 1/1] video-degradation: Don't crash when CL build fails | pippin@gimp.org | 15 May 20:29 |
video-degradation test (was: Re: [PATCH 1/1] video-degradation: Don't crash when CL build fails) | Jan Vesely | 16 May 18:24 |
[PATCH 1/1] video-degradation: Don't crash when CL build fails
Signed-off-by: Jan Vesely
---
operations/common/video-degradation.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/operations/common/video-degradation.c b/operations/common/video-degradation.c
index 29197ff..5b84e2a 100644
--- a/operations/common/video-degradation.c
+++ b/operations/common/video-degradation.c
@@ -201,13 +201,17 @@ cl_process (GeglOperation *operation,
const size_t gbl_size[2] = {roi->width, roi->height};
const size_t gbl_off[2] = {roi->x, roi->y};
cl_int cl_err = 0;
+ cl_mem filter_pat = NULL;
- cl_mem filter_pat = gegl_clCreateBuffer (gegl_cl_get_context (),
- CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR,
- pattern_width[o->pattern] *
- pattern_height[o->pattern] * sizeof(cl_int),
- (void*)pattern[o->pattern],
- &cl_err);
+ if (!cl_data)
+ goto error;
+
+ filter_pat = gegl_clCreateBuffer (gegl_cl_get_context (),
+ CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR,
+ pattern_width[o->pattern] *
+ pattern_height[o->pattern] * sizeof(cl_int),
+ (void*)pattern[o->pattern],
+ &cl_err);
CL_CHECK;
cl_err = gegl_cl_set_kernel_args (cl_data->kernel[0],
sizeof(cl_mem), &in_buf,
2.5.5
[PATCH 1/1] video-degradation: Don't crash when CL build fails
Please use bugzilla which is GEGLs normal patch/bug handling system. I've pushed these changes to git master - albeit with slightly deteriorated meta data since the diffs were manually incorporated.
/pippin
On Sun, May 15, 2016 at 1:04 AM, Jan Vesely wrote:
Signed-off-by: Jan Vesely
---
operations/common/video-degradation.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)diff --git a/operations/common/video-degradation.c b/operations/common/video-degradation.c index 29197ff..5b84e2a 100644
--- a/operations/common/video-degradation.c +++ b/operations/common/video-degradation.c @@ -201,13 +201,17 @@ cl_process (GeglOperation *operation, const size_t gbl_size[2] = {roi->width, roi->height}; const size_t gbl_off[2] = {roi->x, roi->y}; cl_int cl_err = 0;
+ cl_mem filter_pat = NULL;- cl_mem filter_pat = gegl_clCreateBuffer (gegl_cl_get_context (), - CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, - pattern_width[o->pattern] * - pattern_height[o->pattern] * sizeof(cl_int), - (void*)pattern[o->pattern], - &cl_err); + if (!cl_data)
+ goto error;
+
+ filter_pat = gegl_clCreateBuffer (gegl_cl_get_context (), + CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR, + pattern_width[o->pattern] * + pattern_height[o->pattern] * sizeof(cl_int), + (void*)pattern[o->pattern], + &cl_err); CL_CHECK;
cl_err = gegl_cl_set_kernel_args (cl_data->kernel[0], sizeof(cl_mem), &in_buf, --
2.5.5_______________________________________________ gegl-developer-list mailing list
List address: gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[PATCH 1/1] video-degradation: Don't crash when CL build fails
On Sun, 2016-05-15 at 14:12 +0200, Øyvind Kolås wrote:
Please use bugzilla which is GEGLs normal patch/bug handling system. I've pushed these changes to git master - albeit with slightly deteriorated meta data since the diffs were manually incorporated.
thank you, I'll use bugzilla next time. I assumed everybody just uses git am.
The unexpected part is that the test now passes, despite not doing any processing. I have attached diff between reference and OpenCL result. note that CPU version of the algorithm produces the exact same picture as OpenCL (which did no processing)
Jan
/pippin
On Sun, May 15, 2016 at 1:04 AM, Jan Vesely wrote:
Signed-off-by: Jan Vesely
---
operations/common/video-degradation.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)diff --git a/operations/common/video-degradation.c b/operations/common/video-degradation.c index 29197ff..5b84e2a 100644
--- a/operations/common/video-degradation.c +++ b/operations/common/video-degradation.c @@ -201,13 +201,17 @@ cl_process (GeglOperation *operation, const size_t gbl_size[2] = {roi->width, roi->height}; const size_t gbl_off[2] = {roi->x, roi->y}; cl_int cl_err = 0;
+ cl_mem filter_pat = NULL;- cl_mem filter_pat = gegl_clCreateBuffer (gegl_cl_get_context (), - CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR,
- pattern_width[o-pattern] *
- pattern_height[o-
pattern] * sizeof(cl_int),
- (void*)pattern[o-
pattern],
- &cl_err); + if (!cl_data)
+ goto error;
+
+ filter_pat = gegl_clCreateBuffer (gegl_cl_get_context (), + CL_MEM_READ_ONLY | CL_MEM_COPY_HOST_PTR,
+ pattern_width[o->pattern] * + pattern_height[o->pattern] * sizeof(cl_int),
+ (void*)pattern[o->pattern], + &cl_err); CL_CHECK;
cl_err = gegl_cl_set_kernel_args (cl_data->kernel[0], sizeof(cl_mem), &in_buf, --
2.5.5_______________________________________________ gegl-developer-list mailing list
List address: gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-devel oper-list
Jan Vesely
[PATCH 1/1] video-degradation: Don't crash when CL build fails
On Sun, May 15, 2016 at 04:03:22PM -0400, Jan Vesely wrote:
On Sun, 2016-05-15 at 14:12 +0200, yvind Kols wrote:
Please use bugzilla which is GEGLs normal patch/bug handling system. I've pushed these changes to git master - albeit with slightly deteriorated meta data since the diffs were manually incorporated.
thank you, I'll use bugzilla next time. I assumed everybody just uses git am.
We do use git am formatted patches - but attached to bugs in bugzilla instead of sent to the mailinglist - they might linger for a while, but at least not be forgotten like messages to the mailinglist more readily might be. I have workflows for picking patches from bugzilla attachements, but no sensible way to get your contribution without more manual intervention out of the mail (clients).
The unexpected part is that the test now passes, despite not doing any processing. I have attached diff between reference and OpenCL result. note that CPU version of the algorithm produces the exact same picture as OpenCL (which did no processing)
Odd,. both http://gegl.org/operations.html#gegl%3Avideo-degradation and https://git.gnome.org/browse/gegl/plain/tests/compositions/reference/video-degradation.png seem to have processing happening to me.
/pippin
video-degradation test (was: Re: [PATCH 1/1] video-degradation: Don't crash when CL build fails)
On Sun, 2016-05-15 at 20:29 +0000, pippin@gimp.org wrote:
On Sun, May 15, 2016 at 04:03:22PM -0400, Jan Vesely wrote:
On Sun, 2016-05-15 at 14:12 +0200, Øyvind Kolås wrote:
Please use bugzilla which is GEGLs normal patch/bug handling system.
I've pushed these changes to git master - albeit with slightly deteriorated meta data since the diffs were manually incorporated.thank you, I'll use bugzilla next time. I assumed everybody just uses
git am.We do use git am formatted patches - but attached to bugs in bugzilla instead
of sent to the mailinglist - they might linger for a while, but at least not be
forgotten like messages to the mailinglist more readily might be. I have
workflows for picking patches from bugzilla attachements, but no sensible way
to get your contribution without more manual intervention out of the mail
(clients).The unexpected part is that the test now passes, despite not doing any
processing. I have attached diff between reference and OpenCL result.
note that CPU version of the algorithm produces the exact same picture
as OpenCL (which did no processing)Odd,. both http://gegl.org/operations.html#gegl%3Avideo-degradation and
https://git.gnome.org/browse/gegl/plain/tests/compositions/reference/ video-degradation.png
seem to have processing happening to me.
I investigated a bit further:
$ rm tests/compositions/output/*
$ GEGL_USE_OPENCL=no make check
...
/home/vesely/gegl/tests/compositions/reference/video-degradation.png and /home/vesely/gegl/tests/compositions/output/video-degradation.png are identical
PASS video-degradation.xml
SKIP video-degradation.xml (OpenCL)
...
$ diff /home/vesely/gegl/tests/compositions/reference/video-degradation.png /home/vesely/gegl/tests/compositions/output/video-degradation.png
Binary files /home/vesely/gegl/tests/compositions/reference/video-degradation.png and /home/vesely/gegl/tests/compositions/output/video-degradation.png differ
$ compare /home/vesely/gegl/tests/compositions/reference/video-degradation.png /home/vesely/gegl/tests/compositions/output/video-degradation.png -compose src diff-cpu.png
(see attachment)
with OpenCL (unconditionally goto error), the cpu output is the same as above, and comparing opencl output gives: /home/vesely/gegl/tests/compositions/reference/video-degradation.png and /home/vesely/gegl/tests/compositions/output/video-degradation.png are identical PASS video-degradation.xml
(lt-gegl:6636): GLib-GObject-WARNING **: Two different plugins tried to register 'GeglOpload_c'.
(lt-gegl-imgcmp:6662): GLib-GObject-WARNING **: Two different plugins tried to register 'GeglOpload_c'.
/home/vesely/gegl/tests/compositions/reference/video-degradation.png and /home/vesely/gegl/tests/compositions/output/opencl-video-degradation.png are identical
PASS video-degradation.xml (OpenCL)
$ diff ~/gegl/tests/compositions/output/video-degradation.png ~/gegl/tests/compositions/output/opencl-video-degradation.png
$
fixing the original OpenCL error produces the same output as CPU version.
am I doing something wrong?
Jan
/pippin
Jan Vesely