This is my first post in this forum. Hence, if I chose the wrong category, please be so kind and move this post where it belongs to.
I am playing around with the non-blocking use of the various enqueue calls. I must say I really like the way the OpenCL Wait Objects are set up.
I came across one issue, though, that I couldn't explain. I don't think it makes sense to show my code here because it uses a self-made cloo-alike .NET wrapper around the OpenCL functions.
I logically do the following:
- Create a context for one device[/*:m:c0dyujol]
- Create a command queue[/*:m:c0dyujol]
- In an endless loop, I do:
- Allocate a large chunk of memory on the host[/*:m:c0dyujol]
- Create a new buffer with the same size[/*:m:c0dyujol]
- Enqueue a non-blocking copy from the host memory to the buffer (clEnqueueWriteBuffer)[/*:m:c0dyujol]
- put the memory, buffer and returned event in a list so I can still reference them afterwards[/*:m:c0dyujol]
until either OpenCL returns an error (synchronously) or I run our of host memory.[/*:m:c0dyujol][/list:u:c0dyujol]
When I execute this, I always run out of host memory first. It seems I can move much more data to the device (a GPU) than it actually has memory to store it.
Up until now, everything's fine. This was expected, these are non-blocking calls, so they won't error immediately or will just wait until there is enough space. And now comes the Issue: When I check the execution status (clGetEventInfo), all the events are CL_COMPLETE.
From the spec I would have expected the execution status of the later events to be one of two options:
- CL_QUEUED to indicate the operation is queued but cannot run because there is not enough space available on the gpu[/*:m:c0dyujol]
- An out of memory error code to indicate that there is not enough space available on the device[/*:m:c0dyujol]
Is what I observe the correct behaviour? Where does the overflowing data live, then?
Any explanation is highly appreciated.