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
