[Intel-gfx] [PATCH 01/11] drm/i915: flush CPU wc cache when flushing GTT write domain

Eric Anholt eric at anholt.net
Tue Jan 26 18:30:34 CET 2010


On Fri, 15 Jan 2010 13:24:08 +0100, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> There are no other instructions that force the CPU to flush the wc
> buffer before we tear down the corresponding fence reg with a
> pipelined write. IIRC this _might_ get reordered, so enforce correct
> ordering with a posting read to a harmless reg.

The fence reg is uncached.  I checked with jbarnes, and it sounds like
what we've been doing is safe.

<anholt> jbarnes: also interested in your opinion on danvet's changes
for potential reordering of wc aperture writes around uc mmio register
writes.  necessary?
<jbarnes> on intel-gfx?
<anholt> yeah, 11-patch series to drm to make flush_gtt do a read and
then reordering things so that happens before fence regs are cleared.
<anholt> the worry being that wc write posting would get delayed until
after the regs are cleared, and then tile swizzling wouldn't happen
<jbarnes> hm possible for pure writes I think, lemme check the docs
<anholt> figured you'd have the reference handy
<jbarnes> docs say WC is unordered wrt to cacheable mem
<jbarnes> no mention of uncached, but it's probably safe to assume
<anholt> assume unordered?
<jbarnes> oh no
<jbarnes> "writes may be delayed until ... a read or write to uncached
memory"
<jbarnes> at that point the wc buffer will be flushed
<jbarnes> vol 3a, chap 10-6

So, it looks like this series isn't required.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100126/50180979/attachment.sig>


More information about the Intel-gfx mailing list