[Intel-gfx] [PATCH] drm/i915: Don't let a device flush to prepare buffers clear new write_domains.

[Eric Anholt]

On Fri, 2009-02-20 at 07:47 -0800, Keith Packard wrote:
> On Fri, 2009-02-20 at 12:12 +0000, Chris Wilson wrote:
> 
> > Whilst looking at the domain checking, I think one case is missing
> > during the validation. AIUI, a write object must have read_domains ==
> > write_domain.
> 
> That's certainly makes things easier to understand, but it's not
> necessary. Imagine a batch buffer which first reads through the texture
> cache and then writes to the same object through the render cache. That
> batch buffer would need to ensure that both texture and render caches
> were prepared for reading and then it would leave the buffer with data
> in the render cache.
> 
> You'll see that Eric also posted a patch to Mesa which eliminated one
> case where it (incorrectly) specified texture|render, render. That fixed
> lots of Mesa issues even without having the GEM bug fixed.

A little more detail here:

If our object is currently in the
(render,render)
state and the batch buffer has a series of:
(texture, 0)
(render, render)

Then our resulting pending values are:
(texture|render, render)

So we end up flushing the write domain to get us ready for texture read
and invalidating the texture domain, and the end state of the object is:
(texture|render, render).  I think it ends up working:

If the next request is (texture, 0) flush render and invalidate texture.
If the next request is (render, 0), do nothing.
If the next request is (render, render), clear the texture domain.

Having something marked as having write_domain && read_domains !=
write_domain makes me feel really uncomfortable, because it's wrong.
But I haven't come up with the case where the wrong thing happens yet.

-- 
Eric Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20090220/f9821a25/attachment.sig>