#4 Return Events

[Keldor]

The various enqueue functions in CL10 generally return an event as one of their return values. It would be useful to have the Cloo wrappers for these also return that event, since it is useful to query the execution status from that event to load balance across multiple devices (or WOULD be useful if Nvidia's backend for this wasn't broken...).

e.g.

public ComputeEvent Execute( ComputeKernel kernel, long[] globalWorkOffset, long[] globalWorkSize, long[] localWorkSize, ICollection<ComputeEvent> events )
{
IntPtr[] eventHandles = Tools.ExtractHandles( events );
IntPtr newEventHandle = IntPtr.Zero;

unsafe
{
fixed( IntPtr* globalWorkOffsetPtr = Tools.ConvertArray( globalWorkOffset ) )
fixed( IntPtr* globalWorkSizePtr = Tools.ConvertArray( globalWorkSize ) )
fixed( IntPtr* localWorkSizePtr = Tools.ConvertArray( localWorkSize ) )
fixed( IntPtr* eventHandlesPtr = eventHandles )
{
ComputeErrorCode error = CL10.EnqueueNDRangeKernel(
Handle,
kernel.Handle,
globalWorkSize.Length,
globalWorkOffsetPtr,
globalWorkSizePtr,
localWorkSizePtr,
eventHandles.Length,
eventHandlesPtr,
out newEventHandle );
ComputeException.ThrowOnError( error );
}
}
if( events != null )
events.Add( new ComputeEvent( newEventHandle, this ) );
return new ComputeEvent(newEventHandle, this);
}

[nythrix]

Current implementation appends the new event at the end of the collection of events you provide. Have you encountered problems with that approach?

I don't want to tie my hands with returning events just yet. However, it is a sound request and I shall keep it in mind.

I have more elaborate plans concerning compute events. New functionality will be available through ComputeEventList such as direct access to the last event or even some sort of .NET event firing if possible.

[Keldor]

The list of events you provide are there so that the code blocks until those events are complete. Thus, if I want to have an event so I can query completion asynchronously, I have to pass in no events, but I need the event from the queue to be output back. Though maybe I could pass in an empty collection?

[nythrix]

Only the commands that take an explicit blocking flag can block (Finish() and Wait() aside). The rest should be non-blocking by default. "Should be" means it's not explicitly stated by Khronos but every implementer worth his name will go down that road. After all their original names start with "clEnqueue*()" so you'd expect just that.

The event list merely states how the commands should line up one after another in case OutOfOrderExecution is enabled. They don't affect blocking/non-blocking behavior.

[nythrix]

"Thus, if I want to have an event so I can query
completion asynchronously..."
Beware of one thing here. Even if your query returns an ExecutionStatus.Complete it is not guaranteed that the memory objects associated with the event are usable for the next commands.
See: http://www.khronos.org/opencl/sdk/1.0/docs/man/xhtml/clGetEventInfo.html

[Keldor]

"Even if your query returns an ExecutionStatus.Complete it is not guaranteed that the memory objects associated with the event are usable for the next commands."

What on earth is that supposed to mean??

[nythrix]

This is the exact statement from Khronos:
"Using clGetEventInfo to determine if a command identified by event has finished execution (i.e. CL_EVENT_COMMAND_EXECUTION_STATUS returns CL_COMPLETE) is not a synchronization point. There are no guarantees that the memory objects being modified by command associated with event will be visible to other enqueued commands."
Given that ExecutionStatus is built over clGetEventInfo it is subject to the same limitations. You cannot assume much even if ComputeEvent.ExecutionStatus tells you Completed. You should explicitly use synchronization points such as CommandQueue.Finish() to stay on the safe side.

[nythrix]

After much thought, I decided to not implement this feature.
Currently, command queue methods create and append an event to an event list only if such is provided. Having them create events all the time poses unnecessary stress to the GC, which will be collecting an excessive amount of event objects.
In extreme situations you might even run out of OpenCL memory (where the event data is stored) because it is consumed faster than the managed memory (where only the pointer is stored). The GC cannot know about this and so it needn't kick in to dispose events when it should.

[nythrix]

You can use the event lists to achieve this functionality.