On Thu, 12 Sep 2019 at 23:33, Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> wrote: > > Quoting Dave Airlie (2019-08-13 22:20:52) > > On Sat, 10 Aug 2019 at 08:26, Matthew Auld <matthew.auld@xxxxxxxxx> 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. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
