Re: [Intel-gfx] [PATCH 0/2] drm/i915: Remove frontbuffer tracking from gem.

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 01/12/2022 22:03, Zanoni, Paulo R wrote:
> Hi
> 
> I was given a link to https://patchwork.freedesktop.org/series/111494/
> but can't seem to find it on the mailing list, so I'll reply here.
> 
> On Thu, 2022-08-25 at 08:46 +0200, Maarten Lankhorst wrote:
>> Frontbuffer tracking in gem is used in old drivers, but nowadays everyone
>> calls dirtyfb explicitly. Remove frontbuffer tracking from gem, and
>> isolate it to display only.
> 
> Ok, but then how can the Kernel know if the user space running is an
> "old driver" or a new one? Assuming everybody is following the new
> policy is at least risky.
> 
> (crazy idea: have an ioctl for user space to tell whether it knows how
> to DirtyFB and another where it can even say it will never be touching
> frontbuffers at all)
> 
> Also, when I wrote igt/kms_frontbuffer_tracking, it was agreed that
> whatever was there was a representation of the "rules" of the
> frontbfuffer writing contract/API. And I see on the link above that the
> basic tests of kms_frontbuffer_tracking fail. If
> kms_frontbuffer_tracking requires change due to i915.ko having changed
> the frontbuffer writing rules, then we should do it, and possibly have
> those rules written somewhere.
> 
> But then, having the Kernel change expectations like that is not
> exactly what I learned we should be doing, because it's the recipe to
> break user space.
> 
> I'm confused, please clarify us a little more. More sentences in the
> commit messages would be absolutely great.

Right, +1 - we need to be sure there aren't some binaries, running in a 
distro somewhere, or whatever, which rely on this and then we are not 
allowed to break them. As minimum at least we need an audit and versions 
to know how old libraries/programs we are talking about here ie. when 
did everyone stop relying on implicit tracking.

Regards,

Tvrtko