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

Marek Olšák maraeo at gmail.com
Sat Aug 1 09:57:13 PDT 2015

No, we don't need this. radeonsi doesn't return a NULL fence anymore.


On Sat, Aug 1, 2015 at 6:54 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

More information about the mesa-dev mailing list