[Intel-gfx] [PATCH v2 0/5] drm/i915: Allow user to set cache at BO creation

[Yang, Fei]

> On 26/04/2023 07:24, fei.yang at intel.com wrote:
>> From: Fei Yang <fei.yang at intel.com>
>>
>> The first three patches in this series are taken from
>> https://patchwork.freedesktop.org/series/116868/
>> These patches are included here because the last patch
>> has dependency on the pat_index refactor.
>>
>> This series is focusing on uAPI changes,
>> 1. end support for set caching ioctl [PATCH 4/5]
>> 2. add set_pat extension for gem_create [PATCH 5/5]
>>
>> v2: drop one patch that was merged separately
>>      341ad0e8e254 drm/i915/mtl: Add PTE encode function
>
> Are the re-sends for stabilizing the series, or focusing on merge?

v2 was sent just to drop one of patches that has already been merged.

> If the latter then opens are:
>
> 1) Link to Mesa MR reviewed and ready to merge.
>
> 2) IGT reviewed.
>
> 3) I raised an open that get/set_caching should not "lie" but return an
> error if set pat extension has been used. I don't see a good reason not
> to do that.

I don't think it's "lying" to the userspace. the comparison is only valid
for objects created by KMD because only such object uses the pat_index
from the cachelevel_to_pat table.

> + Joonas on this one.
>
> 4) Refactoring as done is not very pretty and I proposed an idea for a
> nicer approach. Feasible or not, open for discussion.

Still digesting your proposal. but not sure how would you define things
like PAT_UC as that is platform dependent, not a constant.
- Fei

> At a push I can look past that and someone can attempt to tidy the
> driver later.
>
> But without 1-3 we cannot merge this.
>
> Regards,
>
> Tvrtko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230426/fdcdc3a6/attachment.htm>