> On 20/04/2023 12:39, Andi Shyti wrote:
>> Hi Fei,
>>
>>> To comply with the design that buffer objects shall have immutable
>>> cache setting through out their life cycle, {set, get}_caching ioctl's
>>> are no longer supported from MTL onward. With that change caching
>>> policy can only be set at object creation time. The current code
>>> applies a default (platform dependent) cache setting for all objects.
>>> However this is not optimal for performance tuning. The patch extends
>>> the existing gem_create uAPI to let user set PAT index for the object
>>> at creation time.
>>> The new extension is platform independent, so UMD's can switch to using
>>> this extension for older platforms as well, while {set, get}_caching are
>>> still supported on these legacy paltforms for compatibility reason.
>>>
>>> Cc: Chris Wilson <chris.p.wil...@linux.intel.com>
>>> Cc: Matt Roper <matthew.d.ro...@intel.com>
>>> Cc: Andi Shyti <andi.sh...@linux.intel.com>
>>> Signed-off-by: Fei Yang <fei.y...@intel.com>
>>> Reviewed-by: Andi Shyti <andi.sh...@linux.intel.com>
>>
>> because this is an API change, we need some more information
>> here.
>>
>> First of all you need to CC the userspace guys that have been
>> working on top of your series and get their ack's.
>
> Yes, and a link to a Mesa merge request which uses the uapi should be
> included.Working with Mesa team on this, stay tuned. > IGTs should be ready to before we can merge. I glanced over igt-dev but > did not spot anything. There is a IGT patch posted to gfx-internal-devel, titled "test/gem_create: exercise gem_create_ext_set_pat" > Regards, > > Tvrtko > >> >> I also believe that this series has also been tested on a >> separate repository, would you link it in the commit message? >> >> Thanks, >> Andi
