Re: [RFC PATCH 0/3] Introducing I915_FORMAT_MOD_4_TILED_XE2_CCS Modifier for Xe2

[Kenneth Graunke <kenneth.w.graunke@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 3403 bytes --]

On Tuesday, May 7, 2024 3:56:57 PM PDT Matt Roper wrote:
> On Mon, May 06, 2024 at 09:52:35PM +0300, Juha-Pekka Heikkila wrote:
> > These patches introduce I915_FORMAT_MOD_4_TILED_XE2_CCS modifier, which,
> > from the kernel's perspective, behaves similarly to 
`I915_FORMAT_MOD_4_TILED`.
> > This new modifier is primarily intended for user space to effectively 
monitor
> > compression status, especially when dealing with a mix of compressed and
> > uncompressed buffers.
> > 
> > The addition of this modifier facilitates user space in managing 
compression
> > status, particularly when utilizing both compressed and uncompressed 
buffers
> > concurrently. To leverage compression for these buffers, user space
> > applications must configure the appropriate Page Attribute Table (PAT) 
index.
> > Display engine will treat all Tile4 as if it were compressed under all
> > circumstances on Xe2 architecture.
> 
> I may have missed some discussion about this, but I thought the previous
> consensus was that we didn't want/need new modifiers for compression on
> Xe2?  If a userspace client (or the display hardware) receives a buffer
> of unknown origin and unknown compression status, it's always fine to
> select a compressed PAT when binding the buffer to read since even for
> uncompressed buffers the CCS metadata will accurately reflect the
> compression status.  Unlike Xe1, where generating content without
> compression enabled would leave random garbage in the FlatCCS area, Xe2
> will set the corresponding FlatCCS to '0x0' for each block, indicating
> uncompressed data.
> 
> Can you explain more what the benefit of handling these modifiers
> explicitly is?
> 
> 
> Matt

Thanks, Matt!  I'm a bit late in getting up to speed with the Xe2 compression 
changes; this is really good information.

As I understand it...all blocks on the GPU behave in the way you mentioned, 
where generating uncompressed data via the GPU will set FlatCCS = 0, so you 
can assume a compressed PAT entry and everything works.

One snag is...I've heard that CPU access doesn't work that way.  So, if you 
mmap a buffer on the CPU, and write data with the CPU, then I think we're back 
to the "FlatCCS contains uninitialized garbage" case, where it's unsafe to 
assume a compressed PAT.  And... we don't really know when sharing buffers 
whether the other side is going to want to do CPU access.

It would be really nice to assume compression by default, though, which got me 
thinking: if we mmap a buffer via DRM_XE_GEM_MMAP_OFFSET, could xe.ko disable 
compression for us?  So, resolve any outstanding CCS data, and then switch any 
PAT entries to uncompressed.  Mapping would block until that resolve is done.  
It could leave compression off forever (once you CPU map a buffer, it's never 
compressed again).  Or it could turn CCS back on when map count reaches 0 (but 
frankly I'm not sure that's terribly important, and sounds more complex).

As I understand it, at least on discrete GPUs, the kernel already has to do 
something similar for eviction, when migrating BOs to system memory (which 
doesn't support compression).  So this would be doing basically the same 
"resolve and disable CCS" step the kernel can presumably already do, but now 
on mmap as well.

What do you think?  Viable?  Crazy?  Have I missed something?

--Ken

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]