Re: [Intel-gfx] Small bar recovery vs compressed content on DG2

[Matthew Auld <matthew.auld@intel.com>]

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