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

[Joonas Lahtinen]

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.

Regards, Joonas