cancel
Showing results for 
Search instead for 
Did you mean: 

OpenCL

franzreitner
Journeyman III

Crash in amdocl64.dll

Dear community,

during my current opencl development (Demosaicking on GPU for Nvidia and AMD) I came accross a tiny problem:

- Create an OpenCL object and initialize to process

- Run a kernel without reading back content (yes, quite unusual, but I just wanted to get performance of a kernel)

- Deleting OpenCL object, or do a <targetbuffer>=NULL.

This causes a crash inside a thread created by amdocl64.dll

When I add a clEnqueReadbuffer everything works fine (...and it also works fine without read back on Nvidia ;-).

In ASM-code I can see that the thread tries to copy buffer content, where the source buffer is deleted by my delete(openclobject).

This is not really urgent, but I wanted the AMD developers to know.

Regards,

Franz

franzreitner_0-1674638557722.png

franzreitner_1-1674638605692.png

franzreitner_2-1674638685794.png

 

0 Likes
1 Solution

From the code in SmallOpenCL.cpp, it seems like the application needs to add proper checking before the following code to ensure that these pointers/buffers are not in use at that time.

v1 = NULL;
v2 = NULL;

delete[] winput;

I guess, that's the reason why there is no issue when adding a blocking call like clEnqueueReadBuffer(..,CL_TRUE,..) before the above lines. I think clFinish() or clWaitForEvents will also work in this case.

For example, I see a non-blocking clEnqueueWriteBuffer call, but there is no checking to ensure that the write has finished before deleting the pointers.

The clEnqueueWriteBuffer says that:

If blocking_write is CL_FALSE, the OpenCL implementation will use ptr to perform a nonblocking write. As the write is non-blocking the implementation can return immediately. The memory pointed to by ptr cannot be reused by the application after the call returns. The event argument returns an event object which can be used to query the execution status of the write command. When the write command has completed, the memory pointed to by ptr can then be reused by the application.

View solution in original post

0 Likes
4 Replies
dipak
Big Boss

Thank you for reporting it. I have whitelisted you and moved the post to the OpenCL forum.

Could you please provide the following information to investigate this issue?

1) a minimal reproducible code example, 2) setup information like gpu, driver version etc. , ) clinfo output

Thanks.

0 Likes

Dear dipak,

thanks for the quick reply. Took some time in order to get a reproducable, as it exactly needs my kernel and the processing. Thaught it is easier...

franzreitner_0-1674652425074.png

A small sample can be downloaded here:

https://cloud.pco.de/index.php/s/7UxfMCVjAAvI4m9

Regards,

Franz

0 Likes

Thanks for providing the repro. I will report the issue to the OpenCL team to look into this.

Thanks.

From the code in SmallOpenCL.cpp, it seems like the application needs to add proper checking before the following code to ensure that these pointers/buffers are not in use at that time.

v1 = NULL;
v2 = NULL;

delete[] winput;

I guess, that's the reason why there is no issue when adding a blocking call like clEnqueueReadBuffer(..,CL_TRUE,..) before the above lines. I think clFinish() or clWaitForEvents will also work in this case.

For example, I see a non-blocking clEnqueueWriteBuffer call, but there is no checking to ensure that the write has finished before deleting the pointers.

The clEnqueueWriteBuffer says that:

If blocking_write is CL_FALSE, the OpenCL implementation will use ptr to perform a nonblocking write. As the write is non-blocking the implementation can return immediately. The memory pointed to by ptr cannot be reused by the application after the call returns. The event argument returns an event object which can be used to query the execution status of the write command. When the write command has completed, the memory pointed to by ptr can then be reused by the application.

0 Likes