| Message ID | 20220825064701.768595-1-maarten.lankhorst@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/i915: Remove frontbuffer tracking from gem. | expand |
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. Thanks, Paulo > > Maarten Lankhorst (2): > drm/i915: Remove gem and overlay frontbuffer tracking > drm/i915: Remove special frontbuffer type > > drivers/gpu/drm/i915/display/intel_cursor.c | 6 +- > drivers/gpu/drm/i915/display/intel_display.c | 4 +- > .../drm/i915/display/intel_display_types.h | 8 +- > drivers/gpu/drm/i915/display/intel_fb.c | 11 +- > drivers/gpu/drm/i915/display/intel_fbdev.c | 7 +- > .../gpu/drm/i915/display/intel_frontbuffer.c | 103 ++---------------- > .../gpu/drm/i915/display/intel_frontbuffer.h | 65 ++--------- > drivers/gpu/drm/i915/display/intel_overlay.c | 14 --- > .../drm/i915/display/intel_plane_initial.c | 3 +- > drivers/gpu/drm/i915/display/intel_psr.c | 1 + > drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 4 - > drivers/gpu/drm/i915/gem/i915_gem_domain.c | 7 -- > .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 - > drivers/gpu/drm/i915/gem/i915_gem_object.c | 25 ----- > drivers/gpu/drm/i915/gem/i915_gem_object.h | 22 ---- > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 4 - > drivers/gpu/drm/i915/i915_driver.c | 1 + > drivers/gpu/drm/i915/i915_drv.h | 1 - > drivers/gpu/drm/i915/i915_gem.c | 8 -- > drivers/gpu/drm/i915/i915_gem_gtt.c | 1 - > drivers/gpu/drm/i915/i915_vma.c | 12 -- > 21 files changed, 35 insertions(+), 274 deletions(-) >
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
On Fri, Dec 2, 2022 at 4:17 AM Tvrtko Ursulin < tvrtko.ursulin@linux.intel.com> wrote: For some reason I has missed this. Thanks Tvrtko for pointing this out. > 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. > Agree. This is a very old problem. That won't go away simply. > > > > (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) > To be honest we had this "crazy" idea back there. But we thought that the frontbuffer tracking would be easiest than new api... We were wrong... and we probably need this now if we want to remove the frontbuffer tracking. > > > > 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 >