cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

pauldoo
Journeyman III

clFlush / clFinish causes application to quit immediately

Stream SDK v2.0 beta2: clFlush / clFinish cause application to quit immediately

I am experimenting with some simple OpenCL code on the Linux 64-bit version of the Stream SDK v2.0 beta2.  I find that in my application my first call to clFlush or clFinish causes the application to die immediately.  Not even my stdout stream is flushed, which has caused me to call "setvbuf(stdout, NULL, _IONBF, 0);" simply to make debugging this far possible.

It isn't that these functions return failure, it's that they don't return, they just take down my app.

The samples that come with the SDK work perfectly so this must be something I'm doing weird.  As I debug further and strip my application down to bare bones, has anyone else experienced this or know what might be the cause?

0 Likes
6 Replies
brg
Staff
Staff

It is quie possible that you are hitting a problem within the CL kernel code and it is being exposed by the clFlush or clFinish. In general, a clFlush or clFinish is required to 'submit' the work enqueued within a given queue and as such it is possible that a kernel is seg-faulting but you are not seeing this until this point.

You could try a couple of things:

1. Check to see if the seg-fault is happening in thread 0, if so then it is not happening in the kernel as this is the host app thread.

2. Try cutting your kernel down to do nothing and see if you still hit the issue, if not then it is likely to be something inside the kernel.

0 Likes

Originally posted by: brg It is quie possible that you are hitting a problem within the CL kernel code and it is being exposed by the clFlush or clFinish. In general, a clFlush or clFinish is required to 'submit' the work enqueued within a given queue and as such it is possible that a kernel is seg-faulting but you are not seeing this until this point.

 

You could try a couple of things:

 

1. Check to see if the seg-fault is happening in thread 0, if so then it is not happening in the kernel as this is the host app thread.

 

2. Try cutting your kernel down to do nothing and see if you still hit the issue, if not then it is likely to be something inside the kernel.

 

 

You were correct, this turned out to be a bug in my kernel code:

http://pauldoo.dyndns.org/svn/OpenCL/WarpOpenCL.cl?p=554

If you look at my setting of "output_pixel", you can see that the level of dereferencing is wrong.  It should have been this:

http://pauldoo.dyndns.org/svn/OpenCL/WarpOpenCL.cl?p=555

 

It's interesting that this didn't show as a compiler warning.

0 Likes
omkaranathan
Adept I

Could you please post your code which is creating issues?

0 Likes

Originally posted by: omkaranathan Could you please post your code which is creating issues?

 

http://pauldoo.dyndns.org/svn/OpenCL/main.c?p=554

Pretty messy I'm afraid.  As I find the time I'll try to strip it down and maybe post another copy.

0 Likes

pauldoo,
Any data that travels to/from a CL device needs to be allocated using the cl_* data types. Also, the kernel code is what is possibly causing the issue here and not the host side app code.

Micah
0 Likes

Pauldoo,
This should give a warning in our next release,
warp_fail.cl(19): warning: a value of type "short" cannot be used to initialize an entity of type "short *const"
short* const output_pixel = output_volume[x + y * width + z * width * height];
^
0 Likes