[Mesa-dev] EXTERNAL: Re: Clover clEnqueue* function don't implement blocking?

[Francisco Jerez]

"Dorrington, Albert" <albert.dorrington at lmco.com> writes:

>> -----Original Message-----
>> From: Francisco Jerez [mailto:currojerez at riseup.net]
>> Sent: Monday, April 14, 2014 4:04 PM
>> To: Dorrington, Albert; mesa-dev at lists.freedesktop.org
>> Subject: RE: EXTERNAL: Re: [Mesa-dev] Clover clEnqueue* function don't
>> implement blocking?
>> 
>> "Dorrington, Albert" <albert.dorrington at lmco.com> writes:
>> >[...]
>> > But when these events are queued, if there isn't a wait(), then what
>> >triggers their flush from the queued_events list?  That seems to only
>> >happen when the hard_event::wait() is called (assuming the status is
>> > queued)
>> >
>> 
>> Yes, that's right, or when clFlush() is called.  So basically we only flush the
>> queued commands to the hardware when the user does some blocking call
>> like reading back a buffer object or waiting for an event explicitly.
>> 
>> > Shouldn't something be flushing the queue as the events are processed
>> > (especially if nothing is pending on the events), well before the
>> > clFinish() call?
>> 
>> I don't have any evidence that doing so would improve performance.
>> Clover tries to minimize the frequency of flushes because it can be quite an
>> expensive operation -- AFAIK for all hardware gallium drivers it involves at
>> least one system call.
>
> From reading the OpenCL spec (and perhaps I'm misinterpreting something again), section 5.10 Flush and Finish says:
>
> 	Any blocking commands queued in a command-queue such as 
> 	clEnqueueRead{Image|Buffer} with blocking_read set to CL_TRUE, 
> 	clEnqueueWrite{Image|Buffer} with blocking_write set to CL_TRUE, 
> 	clEnqueueMap{Buffer|Image} with blocking_map set to CL_TRUE or 
> 	clWaitForEvents perform an implicit flush of the command-queue. 
>
> From this statement, I would expect that the command-queue would be flushed when the blocking flag is set.

clEnqueueRead*, clEnqueueMap* and clWaitForEvents already flush the
command queue (the first two are flushing indirectly as we try to map a
buffer referenced by the GPU).  clEnqueueWrite* doesn't flush, but it's
not clear to me that not doing it can be considered a violation of the
spec.  The guarantees given by clFlush() are rather vague (to some
extent an empty function could be a valid implementation) and it seems
to me that a compliant implementation might, for instance, choose to
batch up commands across flushes if that's the most efficient thing to
do, as long as the user has no way to tell the difference.

I'd like to see some real-world example where clover's behavior
represents a problem before we change it to flush more frequently,
because I'm worried that changing this will actually worsen performance
rather than improving it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140415/848fc8fe/attachment.sig>