42 lines · plain
1gem/gt TODO items2-----------------3 4- For discrete memory manager, merge enough dg1 to be able to refactor it to5 TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has6 improved a lot the past 2 years, there's no reason anymore not to use it.7 8- Come up with a plan what to do with drm/scheduler and how to get there.9 10- Roll out dma_fence critical section annotations.11 12- There's a lot of complexity added past few years to make relocations faster.13 That doesn't make sense given hw and gpu apis moved away from this model years14 ago:15 1. Land a modern pre-bound uapi like VM_BIND16 2. Any complexity added in this area past few years which can't be justified17 with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on18 the bo and vm, plus some lru locks is all that needed. No complex rcu,19 refcounts, caching, ... on everything.20 This is the matching task on the vm side compared to ttm/dma_resv on the21 backing storage side.22 23- i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.24 How-to-dma_fence is core and drivers really shouldn't build their own world25 here, treating everything else as a fixed platform. i915_sw_fence concepts26 should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or27 removed if dri-devel consensus is that it's not a good idea. Once that's done28 maybe even remove it if there's nothing left.29 30Smaller things:31- i915_utils.h needs to be moved to the right places.32 33- dma_fence_work should be in drivers/dma-buf34 35- i915_mm.c should be moved to the right places. Some of the helpers also look a36 bit fishy:37 38 https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/39 40- tasklet helpers in i915_tasklet.h also look a bit misplaced and should41 probably be moved to tasklet headers.42