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

[Jason Ekstrand]

On Thu, May 7, 2020 at 10:44 AM 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

Confident enough to send this patch.  Especially in a Vulkan world
where it's very hard to tell which bits of memory are actually in-use
on the GPU, stalling to relocate is performance death.  With a 48-bit
GTT, there's no need to have the kernel involved in address space
assignment so relocations don't really serve much purpose.  We did
potentially have one use for them with VK_KHR_performance_query but
we're going out of our way to avoid them there.  If we desperately
need relocations, we can do them from userspace.

> and rewrite the media-driver?

I'm pretty sure they're working on getting rid of them.  I'm checking
on that right now.

> The code exists, will be tested, and can just as easily
> expire with the rest of execbuffer2.

Sure.  The question, again, is maintenance.  If we're spending piles
of time trying to figure out how to keep relocations going in a local
memory world, that's likely a waste.  Relocations can sit and rot on
Gen11 and below until we finally make execbuffer3 a reality and then
they can rot in the deprecated execbuffer2 ioct.

There is a bit of a question here about what to do with IGT.  I
suspect it uses relocations for a lot of stuff and the fallout there
could be significant.  (I explicitly made this patch so it won't
actually build because I don't hate our CI people.)

--Jason