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
