[Intel-gfx] [PATCH 08/11] drm/i915: Update write_domains on active list after flush.

Daniel Vetter daniel at ffwll.ch
Mon Feb 1 15:22:33 CET 2010


On Mon, Feb 01, 2010 at 01:17:36PM +0000, Chris Wilson wrote:
> >  	for (i = 0; i < args->buffer_count; i++) {
> >  		struct drm_gem_object *obj = object_list[i];
> > +		struct drm_i915_gem_object *obj_priv = obj->driver_private;
> >  		uint32_t old_write_domain = obj->write_domain;
> >  
> >  		obj->write_domain = obj->pending_write_domain;
> > +		if (obj->write_domain)
> > +			list_move_tail(&obj_priv->gpu_write_list,
> > +				       &dev_priv->mm.gpu_write_list);
> > +		else
> > +			list_del_init(&obj_priv->gpu_write_list);
> > +
> 
> I think the write list must be empty here if the write domain is clear..
> Do you agree?

No. In i915_gem_object_set_to_gpu_domain (used by execbuf code) we update
the obj->(write|read)_domain values, but not the write list.  That's done
at the end of execbuf processing (i.e. exactly the code you're asking
about).

We could of course clear obj_priv->gpu_write_list (if we move to
write_domain != 0 to write_domain == 0) in
i915_gem_object_set_to_gpu_domain and replace the list_del_init in
do_execbuf with a BUG_ON, but I don't think that makes the code more
readable. You have to read & understand the whole do_execbuf logic anyway
to convince yourself that the flush handling is correct.

-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48



More information about the Intel-gfx mailing list