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. Regards, Joonas _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
