On Thu, Jul 12, 2012 at 09:07:52PM +0100, Chris Wilson wrote: > On Thu, 12 Jul 2012 21:37:16 +0200, Daniel Vetter <daniel at ffwll.ch> wrote: > > On Thu, Jul 12, 2012 at 04:13:36PM +0100, Chris Wilson wrote: > > > obj->base.write_domain = 0; > > > - list_del_init(&obj->gpu_write_list); > > > + obj->pending_gpu_write = false; > > > i915_gem_object_move_to_inactive(obj); > > > > Hm, this hunk makes me wonder whether we don't leak some bogus state > > accross a gpu reset. Can't we just reuse the move_to_inactive helper here, > > ensuring that we consistenly clear up any active state? > > Yes. I had planned to finish off with another patch to remove that pair > of then redundant lines, but apparently forgot. I think it is better > expressed as a second patch, at least from the point of view of how I > was applying the transformations. Actually I've been confused yesterday, we do call move_to_inactive in the next line ;-) I've looked again at your patch, and the changes to how we handle obj->pending_pug_write look buggy. The above hunk is superflous, because move_to_inactive will do that. The hunk int i915_gem_execbuffer's is buggy, we can't clear pending_gpu_write there - we use that to decide whether we need to stall for the gpu when the cpu does a read-only accesss. We then stall completely because we don't keep track of the last write seqno separately. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
