Quoting Dave Airlie (2020-07-20 00:52:19) > On Thu, 16 Jul 2020 at 20:11, Matthew Auld <matthew.auld@xxxxxxxxx> wrote: > > > > On 16/07/2020 01:43, Dave Airlie wrote: > > > On Wed, 15 Jul 2020 at 00:35, Matthew Auld <matthew.auld@xxxxxxxxx> wrote: > > >> > > >> On 13/07/2020 06:09, Dave Airlie wrote: > > >>> On Fri, 10 Jul 2020 at 22:00, Matthew Auld <matthew.auld@xxxxxxxxx> wrote: > > >>>> > > >>>> We need to add support for pwrite'ing an LMEM object. > > >>> > > >>> why? DG1 is a discrete GPU, these interfaces we already gross and > > >>> overly hacky for integrated, I'd prefer not to drag them across into > > >>> discrete land. > > >>> > > >>> same goes for pread. > > >>> > > >>> You have no legacy userspace here, userspace needs change to support > > >>> LMEM, it can be fixed to avoid legacy ioctls paths. > > >> > > >> Ok, there have also been similar discussions internally in the past. I > > >> think one of the reasons was around IGT, and how keeping the > > >> pread/pwrite interface meant slightly less pain, also it's not much > > >> effort to implement for LMEM. If this is a NACK, then I guess the other > > >> idea was to somehow fallback to mmap and update IGT accordingly. > > > > > > I just don't think we should have internal kernel interfaces for > > > mapping ram in the kernel address space, seems pointless, makes less > > > sense with a discrete GPU in the mix, so yes I think NAK for > > > pread/pwrite at least at this time. > > > > Ok. > > > > > > > > I'd also like to see a hard no relocs policy for DG1 enforced in the kernel. > > > > Ok, just checking, is that the case even if we don't require extra code > > to support it? We recently dropped the CPU reloc path completely, in > > favour of single GPU reloc path, and so no special code is required to > > support LMEM, it should just work. IGT of course makes heavy use of > > relocs, so that would need an overhaul. > > The GPU reloc path is optimising a path that we simply shouldn't need > or be using. > > IGT tests relocs, ripping out relocs should reduce the amount of > testing IGT has to do and reduce CI run times. Why carry the techincal > debt deliberately. We still have to optimize and keep the the relocations for the older generations, where they are used. So can't really be eliminated from codebase as much of the code is shared. Agreed on the benefit in the more distant future coming from dropping the relocations, once pre-Gen12 hardware is no more. Note that IGT also uses relocations indirectly in non-relocation-specific testtests, so there is quite some work according to our validation team. Wrt this RFC, as no extra code is needed, it is faster to get stack up and running with relocations. It also keeps the changes between iGFX and dGFX minimal, which should help debugging. So that path was taken to get the functional RFC out as fast as possible. Moving away from relocations in both IGT and media driver is being discussed and worked on. See below. > I expect the kernel team to be a bit more authorative inside Intel on > why uAPI gets exposed and why, it seems like everytime there is an > attempt to limit the tech debt of carrying forward unnecessary uAPIs > there is some push back for media driver or IGT. Fix stuff and be > harder in pushing back on carrying unneeded interfaces forward so we > future products are less mired in pointless debt. DG1 uAPI should > really be a chance to full review the legacy of integrated graphics + > pre-48-bit VM interfaces and they should all be turned off for DG1 so > that future discrete GPUs can move forward cleaner. I really shouldn't > be the one enforcing this, the i915 team needs to be a bit > authoritative on what is necessary to support. The patches were sent out as RFC to collect comments. Based on the comments, we're expediting the work to eliminate the use of relocations. Regards, Joonas _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
