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

[Juha-Pekka Heikkila]

On 8.5.2024 1.56, 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.

UMDs have been wishing solution for situation where they receive shared 
bo with unknown compressions status. Problem would arise when 
uncompressed buffer is shared and it's mapped as compressed while 
process which shared bo still would use it as uncompressed. One who 
mapped it last will have correct content on surface while other will 
have have semi-random garbage.

 From what I understand of the compression specifications, all buffers 
should indeed be treated as compressed unless they fall into one of the 
specially listed categories, which are primarily display-related. I 
can't say if this patch set is what is needed to solve UMD issues, I 
don't know why wouldn't user space treat buffers as compressed by default.

> 
> Can you explain more what the benefit of handling these modifiers
> explicitly is?
> 
> 
> Matt
> 
>>
>> Notably, this patch series omits support for X-tiled CCS and linear CCS
>> for Xe2, neither of which is supported by display engine. X-tiled CCS
>> offers stateless compression making it less likely to be extensively
>> utilized. Linear CCS does possess state, but currently lacks expected users.
>>
>> These patches aim to enhance the flexibility and efficiency of handling
>> compressed and uncompressed buffers in Xe driver, particularly
>> catering to the specific requirements of the Xe2 architecture.
>>
>> Juha-Pekka Heikkila (3):
>>    drm/fourcc: define Intel Xe2 related tile4 ccs modifier
>>    drm/xe/display: allow creation of case I915_FORMAT_MOD_4_TILED_XE2_CCS
>>      type framebuffer
>>    drm/i915/display: allow creation of case
>>      I915_FORMAT_MOD_4_TILED_XE2_CCS type framebuffer
>>
>>   drivers/gpu/drm/i915/display/intel_display.c       |  1 +
>>   drivers/gpu/drm/i915/display/intel_fb.c            | 10 ++++++++++
>>   drivers/gpu/drm/i915/display/skl_universal_plane.c |  4 +++-
>>   drivers/gpu/drm/xe/display/xe_plane_initial.c      |  1 +
>>   include/uapi/drm/drm_fourcc.h                      | 12 ++++++++++++
>>   5 files changed, 27 insertions(+), 1 deletion(-)
>>
>> -- 
>> 2.43.2
>>
>