clEnqueueSVMUnmap

[bananAshkar]

about the function clEnqueueSVMUnmap , what happens if we call this function without calling clEnqueueSVMMap first? this is not well-defined in openCL 3.0 Reference Page (spec)

[bashbaug]

Interesting question.

We currently say for the description of the svm_ptr argument to clEnqueueSVMUnmap:

svm_ptr is a pointer that was specified in a previous call to clEnqueueSVMMap. If svm_ptr is allocated using clSVMAlloc then it must be allocated from the same context from which command_queue was created. Otherwise the behavior is undefined.

IMHO this is ambiguous whether "otherwise the behavior is undefined" applies to just the sentence about being allocated from the same context as the command queue or whether it applies to svm_ptr being a pointer previously used with clEnqueueSVMMap also.

The only relevant error condition is:

CL_INVALID_VALUE if svm_ptr is NULL.

Do you have a preference how you would like this to behave?

It would also be interesting to know how different implementations behave in this case.

[aharon-abramson]

In our implementation, we don't check if the buffer has been mapped or not, and we perform the unmapping operation anyway, which may be redundant, but harmless.
I believe that returning an error would be better in this case.

[kpet]

We (Arm) return CL_INVALID_VALUE in that case. We'd support this becoming the specified behaviour.

[bashbaug]

I tried a couple of Intel OpenCL implementations and it looks like our CPU implementation returns CL_INVALID_VALUE for this case and our GPU implementation returns CL_SUCCESS. I saw similar mixed behavior in a couple of the non-Intel OpenCL implementations I tried, too.

I don't think it would be too hard for our GPU implementation to return an error if this is what we decide to do. Theoretically this could cause an app to fail, since we would be returning an error (and not generating an event) when we weren't previously, but this probably won't be a problem, especially given that other OpenCL implementations are generating an error in this case.

In case it's helpful: https://github.com/bashbaug/SimpleOpenCLSamples/blob/svm-unmap-test/samples/99_svmunmap/main.cpp

[lakshmih]

Our (Qualcomm) implementation returns CL_INVALID_VALUE for this situation.

[karolherbst]

We don't return an error in Mesa for this, but it would be consistent with clEnqueueUnmapMemObject to return one.

[bashbaug]

Discussed in the August 22nd teleconference:

• Implementations should return an error in this case - CL_INVALID_VALUE.
• We don't currently have a CTS test for this case, but we'll look into adding one (pending a negative testing discussion).

[bashbaug]

I have a (draft) PR written up that adds this error condition in #979, but I'm starting to have second thoughts whether it is actually possible to reliably return an error in this case. Consider a tricky case like the following (pseudocode):

event1 = clCreateUserEvent();
clEnqueueSVMUnmap(queue1, ptr, depends on event1);

event0 = clCreateUserEvent();
clEnqueueSVMMap(queue0, ptr, depends on event0);

Observations are:

1. We can't determine at the call to clEnqueueSVMUnmap whether the ptr is mapped or not - if event0 is set to complete first then the map will execute first, and if event1 is set to complete first then the unmap will execute first.
2. There are other cases without using user events where an SVM map may execute before an SVM unmap but where there are no guarantees.
3. Buffer and image memory objects don't have a similar problem for two reasons: the pointer to unmap is (usually) unknown until the memory object is mapped, therefore as a practical matter the call to map the memory object must (usually) occur before the call to unmap the memory object. It is also possible to query the memory object's map count, which provides another mechanism to determine if the memory object has been mapped or not.

Given (3), is the expectation that implementations track which SVM regions have been mapped similarly, even though there is (currently) no queryable map count? Should the example above generate an error because clEnqueueSVMUnmap was called before clEnqueueSVMMap, even though the map may actually execute before the unmap?

[aharon-abramson]

Given your interesting examples, I believe we can live without this error case. However, maybe we need a note in the spec to explain why we don't handle this case.