No, we don't need this. radeonsi doesn't return a NULL fence anymore. Marek
On Sat, Aug 1, 2015 at 6:54 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 16 July 2015 at 19:16, Tom Stellard <t...@stellard.net> wrote: >> On Sat, Jul 11, 2015 at 02:35:53PM +0300, Francisco Jerez wrote: >>> Tom Stellard <thomas.stell...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
