[Intel-gfx] [PATCH 04/11] drm/i915: check for multiple write domains in pin_and_relocate

[Daniel Vetter]

On Fri, Jan 15, 2010 at 12:50:05PM +0000, Chris Wilson wrote:
> On Fri, 15 Jan 2010 13:24:11 +0100, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> > Only one write domain is allowed, don't let userspace screw us over.
> 
> Userspace is currently allowed to submit MI_FLUSH into a batch to manage
> the domains, this breaks that, and I've had similar patch vetoed in the
> past for that reason (and now drivers do attempt to be clever...)

Uups, I didn't know this was supposed to be allowed. I disallowed multiple
write domains because I think this screws up the kernel domain tracking.

For example userspaces set the write_domain to DOMAIN_A | DOMAIN_B (and
does some flushes in the batchbuffer to keep caches coherent). The kernel
enforces that read_domains == write_domains, so after this batchbuffer
we have (A|B, A|B) for read/write domains. Save when userspace flushes and
invalidates both domains at the of its batchbuffer, the kernel will not
issue a required flush/invalidate domain when this object gets used
again. And of course, all these flushes happen without the kernel
noticing, potentially requiring more (unneeded) flushes for other objects.

So in conclusion, I think we need a new execbuf ioctl (again) to support
this correctly.  For every object, userspace specifies:
- read/write domains the batchbuffer expects objects to be in when
  starting
- read/write domains this batchbuffer leaves objects in when finished
Furthermore
- read/write domains that get flushed while executing this batchbuffer (to
  update the kernels flushing_list).

Otherwise the whole kernel managed domains idea seems somewhat pointless
to me.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48