[Intel-gfx] [PATCH] drm/i915: Don't let a device flush to prepare buffers clear new write_domains.
eric at anholt.net
Fri Feb 20 12:13:07 PST 2009
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
state and the batch buffer has a series of:
Then our resulting pending values are:
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 at anholt.net eric.anholt at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/intel-gfx/attachments/20090220/f9821a25/attachment.pgp
More information about the Intel-gfx