PDA

View Full Version : Automatic dependancy checking.



thurgold
01-24-2010, 09:09 PM
It looks like open_cl does not check for data dependencies between different tasks that have been submitted.
IE: if one has one kernel that writes to memory region A, and one that reads from memory region A, it is the application developers responsibility to keep them from stepping on each-others toes.

I was wondering if there were already any libraries to work with open-cl that would handle the dependencies. I have a library designed to handle the scheduling of dependent tasks on heterogeneous hardware, but It was written before open-cl. I am thinking of porting it to open-cl, but don't want to bother if there is already a solution.

dbs2
01-25-2010, 01:21 AM
I'm not aware of anyone already doing this for OpenCL. It is possible that implementations do this under the hood to get better performance by re-ordering kernels, but unlikely given the lack of support for multiple/out-of-order executions on current GPU hardware. It would be nice if you could insert such a library between the user accessing OpenCL and the runtime so you could automatically use events to enforce the implicit dependencies, but I'm not sure how easy that would be.

thurgold
02-14-2010, 10:16 PM
I already have some code that can analyze memory regions for overlaps, and build the DAG dependency tree. It looks like all I need to do to adapt this to openCL is extract the address ranges of the backing buffers, and build the dependency lists from the dependency tree. It gets even easier if I assume the buffers do not overlap.

dbs2
02-20-2010, 04:47 AM
I'm not sure how valuable an analysis that looks at overlapping regions would be.
Most cl_mem objects will not overlap. The only ones that might are ones created with CL_MEM_USE_HOST_PTR, and if those overlap then you may get undefined behavior, I believe. The issue with dependencies is that a kernel may write to multiple cl_mems that are then read by other kernels. In that case it is important that the first kernel finish executing before the second one starts. This is an issue for out-of-order queues and multiple queues. Here OpenCL leaves it up to the user to enforce the required dependencies with event wait lists, which effectively force that DAG internally.