[Intel-gfx] [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.


More information about the Intel-gfx mailing list