[PATCH] RFC: i915: Drop relocation support on Gen12+
Dave Airlie
airlied at gmail.com
Thu May 7 18:27:27 UTC 2020
On Fri, 8 May 2020 at 01:44, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>
> Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin which
> > all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12 is
> > only supported by iris which never uses relocations. The older i965
> > driver in Mesa does use relocations but it only supports Intel hardware
> > through Gen11 and has been deprecated for all hardware Gen9+. The entire
> > relocation UAPI and related infrastructure, therefore, doesn't have any
> > open-source userspace consumer starting with Gen12.
> >
> > Rejecting relocations starting with Gen12 has the benefit that we don't
> > have to bother supporting it on platforms with local memory. Given how
> > much CPU touching of memory is required for relocations, not having to
> > do so on platforms where not all memory is directly CPU-accessible
> > carries significant advantages.
>
> You are not supplying them, the kernel is not checking them [as they
> don't exist], so there is no material benefit. The only question is
> maintainability.
>
> How confident are you that you will never use them and rewrite the
> media-driver? The code exists, will be tested, and can just as easily
> expire with the rest of execbuffer2.
>From an upstream POV I say hell yes, if the hw isn't generally available yet,
and the media-driver/intel-compute-runtime people are warned in advance,
I'm all in on ripping it out for new GENs.
Dave.
More information about the dri-devel
mailing list