On Fri, 8 May 2020 at 01:44, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
