[Mesa-dev] [Mesa-stable] [PATCH] clover: Fix bug with computing hard_event status

[Emil Velikov]

On 16 July 2015 at 19:16, Tom Stellard <tom at stellard.net> wrote:
> On Sat, Jul 11, 2015 at 02:35:53PM +0300, Francisco Jerez wrote:
>> Tom Stellard <thomas.stellard at amd.com> writes:
>>
>> > pipe_context::flush() can return a NULL fence if the queue is already
>> > empty, so we should not assume that an event with a NULL fence
>> > has the status of CL_QUEUED.
>> >
>>
>> This seems suspicious...  On the one hand it doesn't seem to be a
>> documented "feature" of pipe_context::flush to return NULL except in
>> error conditions (I'm pretty sure other drivers like nouveau won't), and
>> it seems like it could easily break assumptions of other state trackers.
>>
>> IMO pipe_context::flush() should respect the invariant that whatever is
>> returned in the fence output argument (unless some error occurred) be a
>> valid argument for pipe_screen::fence_finish() and ::fence_signalled()
>> -- I don't think NULL is?
>>
>> On the other hand this leaves me wondering how could the queue already
>> be empty when clover calls pipe_context::flush() -- I assume by queue
>> you mean the pipe driver's?  The fact that clover calls
>> pipe_context::flush() implies that clover's event queue is not empty
>> (i.e. there have been commands enqueued to the pipe driver since the
>> last call to pipe_context::flush()).  It sounds like this mismatch
>> between clover's and the pipe driver's command queue might be caused by
>> some race condition elsewhere?
>>
>> Thanks.
>>
>
> The bug appears in programs which call clFinish() without ever
> adding anything to the command queue.  In this case, radeonsi
> sees that no commands have been submitted to the GPU, so it doesn't
> submit the fence and sets the fence parameter to NULL.
>
Gents, do we still need this considering the recent fixes by
Marek/Michel in radeonsi/r600 ?

-Emil