Re: [PATCH v12 11/13] drm/xe: Force flush system memory AuxCCS framebuffers before scan out

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Fri, Sep 26, 2025 at 10:41:56AM +0300, Ville Syrjälä wrote:
> I reverse engineered this a bit and there's definitely a
> MOCS issue at play.
> 
> First I noticed that if filled the entire MOCS table with
> UC the problem went away. I then filled the entire table
> with WB and essentially bisected what I need to make UC
> to fix it. And I had to repeat that same process starting
> from the other end of table.
> 
> Looks like there is some undocumented magic in the hardware.
> 
> MOCS 61 really is special:
> - MOCS 61 UC, others WB, select MOCS 61 -> no corruption
> 
> MOCS 0 and 63 are special in other ways:
> - MOCS X UC, others WB, select MOCS X -> corruption
> - MOCS X+0 UC, others WB, select MOCS X -> corruption
> - MOCS X+63 UC, others WB, select MOCS X -> corruption
> - MOCS X+0+63 UC, others WB, select MOCS X -> no corruption
>   where X != 61

OK, the MOCS 63 issue was caused by me having L3=WB still in
MOCS X. If I change MOCS X to L3=UC, MOCS 63 no longer makes
a difference. I suppose that means MOCS 63 is still used for
L3 evictions, even though bspec no longer mentions that fact
explicitly.

So MOCS 0 is the thing that really matters for CCS. And for
MOCS 0 only the LLC WB vs. UC selection matters. L3 WB vs. UC
doesn't seem to make any difference.

It's interesting that MOCS 60 is documented as a "CCS special case",
but in reality it's MOCS 0 that matters for CCS. I wonder if some
wires got crossed in the hw design and the wrong MOCS entry ended
up being used for CCS and no one noticed...

> 
> I didn't actually test all values of X there, but I did spot
> check a handful of them.
> 
> Also, ADL is affected, but TGL doesn't seem to be. Though I
> still need to check the situation on TGL a bit more thoroughly.

TGL actually works exactly the same as ADL. The only reason why
TGL worked correctly out of the box was that we use a different
MOCS table for TGL/RKL (IIRC because we started out with the
wrong table and early Mesa versions depended on that), and in
that table MOCS 0 is just 0x0, whereas on ADL MOCS 0 is WB.

And now I'm wondering how much performance we're leaving on
the floor with CCS by having a suboptimal MOCS 0 on TGL/RKL...

And I'm also curious about older platforms. I think those also
have MOCS 0 as UC. I'll need to test if those also have this
MOCS 0 special case for CCS...

-- 
Ville Syrjälä
Intel