CODEWITHSUNDEEP
copenclgpgpu
Shoomla
Shoomla

Reputation: 131

When does OpenCL data transfer occur?

I've seen a few questions here on Stack overflow dealing with the same issues, but no definite answer. I thought I'll ask again, with a bunch of questions of my own. All relate to the subject matter at hand.

So, do we know when the data transfer from host to the openCL device occurs? Can you tell me the exact memory transfer operation of the functions below (that is, what data is transferred or created, if any, when these functions are invoked?):

clCreateBuffer()

clSetKernelArg()

clEnqueueNDRangeKernel()

The first two don't even produce events, so we can't time them, but surely some data transferring is happening here.

Is there a way to transfer data to a device without first setting it as a kernel arg?

It appears (from preliminary testing of my own) that a mem object created with CL_MEM_USE_HOST_PTR gets directly manipulated by the device. Why would that not be desirable, since, that way, we could avoid further data transfer commands (and surely the driver implements this in the most efficient way)?

Does transferred data (say, as par of a kernel arg) stay at the device for further manipulation, after a kernel returns? If not is there a way to do just that?

Upvotes: 2

Views: 644

Answers (1)

huseyin tugrul buyukisik
huseyin tugrul buyukisik

Reputation: 11910

Buffer copies are related to command queues. Command queues are synced with host using finish() as easiest way.

clCreateBuffer()

    clEnqueueWriteBuffer() <-------- you can get event data from this
        (set blocking parameter to false to queue everything quickly)  
        (set blockinig to true if you sync write here)  

clSetKernelArg()

    clEnqueueWriteBuffer() <----- it could be here too

clEnqueueNDRangeKernel()

    clEnqueueWriteBuffer() <----- or here (too quickly re-set an array?)

clFinish() <--------- this ensures all queued commands are executed before this

now you can query data of that event to check when it started and when ended

to let a buffer stay in device, you should create it in device first then don't migrate it to another device. Using only CL_MEM_READ_WRITE flag in createBuffer() is enough to make it a real buffer on device-side until you release that buffer.

CL_MEM_USE_HOST_PTR or CL_MEM_ALLOC_HOST_PTR uses host memory as device maps it to its cores. This is faster for streaming data in and out because of not-needing of extra data movements in host side. If you need to use device memory such as fast gddr5 or hbm always, then you should not use these flags.

Copy to device once, use as much as you want. If device has its own memory of course. For example, Intel HD Graphics 400 doesn't have its own memory and shares RAM so it is much faster to use CL_MEM_..._HOST_PTR flags and especially USE_HOST_PTR.

To check if device shares RAM with CPU, you query CL_DEVICE_HOST_UNIFIED_MEMORY property of device.

It appears (from preliminary testing of my own) that a mem object created with CL_MEM_USE_HOST_PTR gets directly manipulated by the device

Even without map/unmap commands pror to kernel execution, my computer is behaving same, but I'm using map/unmap just to be safe and it doesn't tax too many cycles.

Edit: if you want to make sure a command doesn't start before you want, you can add a user event in event list input parameter of bufferwrite command. Then you can trigger the user event to let writing start because commands wait for all events in the list to be fired+completed before continuing (if there are any specified in event list input parameter)

Upvotes: 2

Related Questions