[PATCH] RFC: i915: Drop relocation support on Gen12+

[Joonas Lahtinen]

Quoting Dave Airlie (2020-05-07 21:27:27)
> 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.

There have been discussions with our media driver team about eliminating
any relocations, but today they are still being used. They have started
partially using soft-pinning, which is a great first step to that
direction.

The compute driver does not rely on relocations, they use soft-pinning
everywhere and explicitly manage the address space.

Be assured that I'm also in favor of eliminating relocations (just like
execbuffer2, userptr and couple other things), just that we still need
to have a functional stack before they can be dropped for new hardware.

Like Chris mentioned, enough optimization have been put in the code so
that there is zero impact from the relocations to the exclusively
soft-pinning drivers. So the sole benefit would be being able to drop
the relocations code in the future when the Gen11 hardware has gone
exctinct and that is a worthy goal, too.

But for now the feature is still needed for Gen12, so forcefully
disabling it is untimely.

Regards, Joonas