CL_INVALID_VALUE in clEnqueueReadBufferRect in JOCLSample_1_1.java


#1

JOCLSample_1_1.java contains following code:

        long bufferRowPitch = sizeX * Sizeof.cl_float;
        long bufferSlicePitch = sizeX * sizeY;
        long hostRowPitch = regionSizeX * Sizeof.cl_float;
        long hostSlicePitch = regionSizeX * regionSizeY;

When I run it I get:

CL_DEVICE_NAME: Pitcairn
Enqueue buffer region read, waiting for user event
Exception in thread "main" org.jocl.CLException: CL_INVALID_VALUE
	at org.jocl.CL.checkResult(CL.java:686)
	at org.jocl.CL.clEnqueueReadBufferRect(CL.java:14304)
	at org.jocl.samples.JOCLSample_1_1.main(JOCLSample_1_1.java:121)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)

However, when I change the code to:

        long bufferRowPitch = sizeX * Sizeof.cl_float;
        long bufferSlicePitch = sizeX * sizeY * Sizeof.cl_float;
        long hostRowPitch = regionSizeX * Sizeof.cl_float;
        long hostSlicePitch = regionSizeX * regionSizeY * Sizeof.cl_float;

I get the following output:

CL_DEVICE_NAME: Pitcairn
Enqueue buffer region read, waiting for user event
Waiting before setting event status to CL_COMPLETE
Seconds left: 3
Seconds left: 2
Seconds left: 1
Setting event status to CL_COMPLETE
Event cl_event[0x7ff6409d00b0] reached status CL_COMPLETE, user data: Event callback user data
Buffer region was read:
 10.0  12.0 
 18.0  20.0 
Memory object cl_mem[0x7ff6403adce0] was destroyed, user data: Memory object destructor callback user data
PASSED

Seems that there’s a bug in the code.


#2

Hello

Thanks for this hint, I’ll have a look at this later today. (The spec says that it should be the pitch in bytes, so from a first glance, it should indeed involve some “Sizeof…”…)

bye
Marco


#3

Just a follow up: I updated the sample according to what you said. But I noticed that I’ll have to take a closer look at this: For my tests, this parameter did not seem to be used at all: I tested passing in “0”, and it worked. In any case, I ran the sample on NVIDIA and AMD, and it worked in both cases. “Pitcairn” is a new AMD GPU? (For AMD, I can only run tests on the CPU, this may make a difference as well…)


#4

“Pitcairn” is Radeon HD 7870.


#5

I see. Usually, AMD tends to be a bit stricter concerning standards and conventions, but it’s still strange that the (probably) wrong value still worked for NVIDIA GPUs and AMD CPUs. Some more test coverage for the border cases may be necessary here.