cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

n_treutner
Journeyman III

errors after Update to SDK 2.2 and OCL 1.1

CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST and CL_INVALID_OPERATION

i actually resolved the errors i got, but i don't know where they came from.

The Problem was:

After I updated to the recent drivers and sdk-files, my kernels didn't work anymore. I got a "-14" error on my waitForEvents (CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST), so i checked the CL_EVENT_COMMAND_ EXECUTION_STATUS, which sometimes was "-59" (CL_INVALID_OPERATION). i checked my operations twice, re-included the headers and so on. after i removed all the code, except for the "header", i figured, it had to be sth with the header, which it was:

i changed a "__constant" variable to a "__global" variable and: tadah, it worked.

the entire kernel-"header", that ceased to work was:

__kernel void RGB2LAB(__constant uchar4 * inputImage1, __write_only image2d_t outputImage)

the constant in question is similar to the one in the box-filter-example. i don't remember, why i had changed it from global to constant.

so: any ideas? i'm just curious (so: no rush), but maybe someone else has a problem like this, too.

0 Likes
6 Replies
genaganna
Journeyman III

Originally posted by: n.treutner i actually resolved the errors i got, but i don't know where they came from.

The Problem was:

After I updated to the recent drivers and sdk-files, my kernels didn't work anymore. I got a "-14" error on my waitForEvents (CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST), so i checked the CL_EVENT_COMMAND_ EXECUTION_STATUS, which sometimes was "-59" (CL_INVALID_OPERATION). i checked my operations twice, re-included the headers and so on. after i removed all the code, except for the "header", i figured, it had to be sth with the header, which it was:

i changed a "__constant" variable to a "__global" variable and: tadah, it worked.

the entire kernel-"header", that ceased to work was:

__kernel void RGB2LAB(__constant uchar4 * inputImage1, __write_only image2d_t outputImage)

the constant in question is similar to the one in the box-filter-example. i don't remember, why i had changed it from global to constant.

so: any ideas? i'm just curious (so: no rush), but maybe someone else has a problem like this, too.

May be you are crossing maximum availabe constant buffer size.  what is the size of inputImage1 and compare value returned by clGetDeviceInfo() with CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE.

0 Likes

thanks for your reply. i guess, you're right.

CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE is 64KB and the Image is 115.2.

but why did it work with 2.2 / 1.0 ? also: why did it throw a "invalid operation"?

again: i'm just curious.

0 Likes

Originally posted by: n.treutner thanks for your reply. i guess, you're right.

 

CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE is 64KB and the Image is 115.2.

 

but why did it work with 2.2 / 1.0 ? also: why did it throw a "invalid operation"?

 

again: i'm just curious.

 

Previously it was mapped to global memory.  Now it is mapped to hardware constant buffer.   With 2.2, You should get error while creating cl_mem buffer for this constant buffer.  Please post your code here if you are not getting any error.

 

0 Likes

It's making sense now, thank you!

But I don't understand, why I should get an error when creating the cl_mem buffer. afaik i don't state, that i am using constant memory when creating the cl_mem, only in my CL-Code. but obviously i'm wrong here. i put together the relevant parts of my code, which are normally distributed along my entire document, i hope it's what you need.

cl_mem inputImageBuffer1;

char * inputImageData1;

inputImageData1 = m_pInputImage1->imageData; // pInputImage1 is an OpenCV Image

inputImageBuffer1 = clCreateBuffer(
            context,
            CL_MEM_READ_ONLY, // | CL_MEM_USE_HOST_PTR,
            width * height * pixelSize,
            NULL,
            &status);

status = clEnqueueWriteBuffer(
            commandQueue,
            inputImageBuffer1,
            CL_TRUE,
            0,
            width * height * pixelSize,
            inputImageData1,
            0,
            NULL,
            &events[0]);

(I have to seperately write to the Buffer, because i create it only once, but write live data (e.g. webcam) to it, while running the program)

is this what you asked for? again, since i use global memory, everything works fine.

0 Likes

Originally posted by: n.treutner It's making sense now, thank you!

 

But I don't understand, why I should get an error when creating the cl_mem buffer. afaik i don't state, that i am using constant memory when creating the cl_mem, only in my CL-Code. but obviously i'm wrong here. i put together the relevant parts of my code, which are normally distributed along my entire document, i hope it's what you need.

 

cl_mem inputImageBuffer1;

 

char * inputImageData1;

 

inputImageData1 = m_pInputImage1->imageData; // pInputImage1 is an OpenCV Image

 

inputImageBuffer1 = clCreateBuffer(             context,             CL_MEM_READ_ONLY, // | CL_MEM_USE_HOST_PTR,             width * height * pixelSize,             NULL,             &status);

 

status = clEnqueueWriteBuffer(             commandQueue,             inputImageBuffer1,             CL_TRUE,             0,             width * height * pixelSize,             inputImageData1,             0,             NULL,             &events[0]);

 

(I have to seperately write to the Buffer, because i create it only once, but write live data (e.g. webcam) to it, while running the program)

 

is this what you asked for? again, since i use global memory, everything works fine.

 

Sorry, It was my mistake.  You should get error at clEnqueueNDRangeKernal not at clCreateBuffer.

0 Likes

yeah, that's about right. after i enqueued it and then flush it (or "waitfor" it), the state changes from 3 to -59, like i said above.

but i get the error only, when i try to get the state of the kernel. so, if i don't ask the kernel, how it feels, i won't know, something is wrong (if you know, what i mean *g*). on the other hand, i wouldn't be able to work with the kernel otherwise. but the clEnqueueNDRangeKernalitself does not give me an error.

0 Likes