On 17/03/2022 08:43, Joonas Lahtinen wrote:
Quoting Thomas Hellström (2022-03-16 09:25:16)
Hi!
Do we somehow need to clarify in the headers the semantics for this?
From my understanding when discussing the CCS migration series with
Ram, the kernel will never do any resolving (compressing /
decompressing) migrations or evictions which basically implies the
following:
*) Compressed data must have LMEM only placement, otherwise the GPU
would read garbage if accessing from SMEM.
This has always been the case, so it should be documented in the uAPI
headers and kerneldocs.
*) Compressed data can't be assumed to be mappable by the CPU, because
in order to ensure that on small BAR, the placement needs to be LMEM+SMEM.
Not strictly true, as we could always migrate to the mappable region in
the CPU fault handler. Will need the same set of tricks as with limited
mappable GGTT in past.
With the proposed I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS hint[1], it
looks like by design we always require lmem + smem, with the idea that
we can always spill to system memory if needed. So I guess explicit
NEEDS_CPU_ACCESS + compression is not supported, is this the expected
behaviour?
[1] https://patchwork.freedesktop.org/patch/475061/
*) Neither can compressed data be part of a CAPTURE buffer, because that
requires the data to be CPU-mappable.
Especially this will be too big of a limitation which we can't really afford
when it comes to debugging.
Regards, Joonas
Are we (and user-mode drivers) OK with these restrictions, or do we need
to rethink?
Thanks,
Thomas
