[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