[Intel-gfx] [PATCH v3 00/37] Introduce memory region concept (including device local memory)

[Dave Airlie]

On Thu, 12 Sep 2019 at 23:33, Joonas Lahtinen
<joonas.lahtinen at linux.intel.com> wrote:
>
> Quoting Dave Airlie (2019-08-13 22:20:52)
> > On Sat, 10 Aug 2019 at 08:26, Matthew Auld <matthew.auld at intel.com> wrote:
> > >
> > > In preparation for upcoming devices with device local memory, introduce the
> > > concept of different memory regions, and a simple buddy allocator to manage
> > > them in i915.
> > >
> > > One of the concerns raised from v1 was around not using enough of TTM, which is
> > > a fair criticism, so trying to get better alignment here is something we are
> > > investigating, though currently that is still WIP so in the meantime v3 still
> > > continues to push more of the low-level details forward, but not yet the TTM
> > > interactions.
> >
> > Can we bump the TTM work up the ladder here, as is I'm not willing to
> > accept any of this code upstream without some serious analysis, this
> > isn't a case of me making a nice suggestion and you having the option
> > to ignore it. Don't make me shout.
>
> Thanks for a reminder. TTM analysis was ongoing on the background
> and we now reserved enough time to conclude on how to best align
> with TTM in short-term and long-term.
>
> We decided to bite the bullet and apply dma_resv as the outer-most
> locking in i915 codepaths to align with the TTM locking. As a
> conclusion to those discussions we documented guidelines how to
> align with TTM locking:
>
> https://patchwork.freedesktop.org/patch/328266/
>
> As refactoring of locking fundamentals of the driver is a massive
> undergoing with many opens along the path, we'd like to propose a
> staged approach to avoid stalling the upstream work while it's
> being done.
>
> Our first suggested step would be merging the i915 local memory
> related internal code reworks to unblock the display work. This
> step should not cause any conflicts with TTM.
>
> Following step would be to merge proposed memory allocation/
> management uAPIs with TTM related functionality behind them for
> early debug. They would be protected by DRM_I915_DEBUG_EARLY_API
> kernel config flag (depending on EXPERT & STAGING & BROKEN).
>
> This would allow us to keep debugging these new IOCTLs with Mesa
> etc. while we rework the locking. The protection still leaving us
> a possibility to correcting the uAPIs if/when there is need after
> reworking the locking around dma_resv progresses. Draft of such
> proposal here:
>
> https://patchwork.freedesktop.org/patch/327908/
>
> The final step (a rather long one) would be then to complete the
> locking rework in the driver and lift the DEBUG_EARLY_API
> protection once the locking has been sorted.
>
> If you could confirm the above plan sounds reasonable to you, we
> may then proceed with it.

Just travelling, but this sounds like a good way foward to me.

Dave.