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

[Joonas Lahtinen]

Quoting Kenneth Graunke (2024-05-11 03:58:34)
> 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.

I think the previous discussion has specifically happened in the context of
dma-buf, so not only CPU but other GPUs/accelerators/decoders/devices in the
system are also relevant.

It boils down to the fact that when exporting a dma-buf, one can't know it will
be consumed only by the same GPU (or other device for that matter) unless there
is an explicit negotiation between exporter and importers.

> 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).

This would only really work for a single device but the dma-buf is
specifically targeting more generic sharing. There's no built-in mechanism
to limit the sharing to subset of devices without explicit negotiation
between the exporter and importers.

So I think the "by default" mode needs to be interoperable, and the
explicit negotiation can then use less compatible formats given those FD
are never passed to importers that were not part of the negotiation.

> 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.

So far the eviction strategy has been to copy both the backing store and
compression bits in raw form. With Xe2 it would indeed be possible to do
an implicit resolve IFF the buffer has not been shared to someone who doesn't
understand compression and might have left garbage in the CCS bits.

When evicting in raw form, kernel doesn't have to know if the CCS bits
are garbage or not on any given moment.

Regards, Joonas

> 
> What do you think?  Viable?  Crazy?  Have I missed something?
> 
> --Ken