On 08/06/15 17:28, Imre Deak wrote: > By running igt/store_dword_loop_render on BXT we can hit a coherency > problem where the seqno written at GPU command completion time is not > seen by the CPU. This results in __i915_wait_request seeing the stale > seqno and not completing the request (not considering the lost > interrupt/GPU reset mechanism). I also verified that this isn't a case > of a lost interrupt, or that the command didn't complete somehow: when > the coherency issue occured I read the seqno via an uncached GTT mapping > too. While the cached version of the seqno still showed the stale value > the one read via the uncached mapping was the correct one. > > Work around this issue by clflushing the corresponding CPU cacheline > following any store of the seqno and preceding any reading of it. When > reading it do this only when the caller expects a coherent view. > > Testcase: igt/store_dword_loop_render > Signed-off-by: Imre Deak <imre.deak@xxxxxxxxx> Not necessarily a cure for this, but BSpec says of MI_STORE_DATA_IMM (and MI_STORE_DATA_INDEX): This command simply initiates the write operation with command execution proceeding normally. Although the write operation is guaranteed to complete "eventually", there is no mechanism to synchronize command execution with the completion (or even initiation) of these operations. So shouldn't we use MI_FLUSH_DW or PIPE_CONTROL to update the seqno in the HWSP instead? .Dave. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
