0001 gem/gt TODO items
0002 -----------------
0003
0004 - For discrete memory manager, merge enough dg1 to be able to refactor it to
0005 TTM. Then land pci ids (just in case that turns up an uapi problem). TTM has
0006 improved a lot the past 2 years, there's no reason anymore not to use it.
0007
0008 - Come up with a plan what to do with drm/scheduler and how to get there.
0009
0010 - Roll out dma_fence critical section annotations.
0011
0012 - There's a lot of complexity added past few years to make relocations faster.
0013 That doesn't make sense given hw and gpu apis moved away from this model years
0014 ago:
0015 1. Land a modern pre-bound uapi like VM_BIND
0016 2. Any complexity added in this area past few years which can't be justified
0017 with VM_BIND using userspace should be removed. Looking at amdgpu dma_resv on
0018 the bo and vm, plus some lru locks is all that needed. No complex rcu,
0019 refcounts, caching, ... on everything.
0020 This is the matching task on the vm side compared to ttm/dma_resv on the
0021 backing storage side.
0022
0023 - i915_sw_fence seems to be the main structure for the i915-gem dma_fence model.
0024 How-to-dma_fence is core and drivers really shouldn't build their own world
0025 here, treating everything else as a fixed platform. i915_sw_fence concepts
0026 should be moved to dma_fence, drm/scheduler or atomic commit helpers. Or
0027 removed if dri-devel consensus is that it's not a good idea. Once that's done
0028 maybe even remove it if there's nothing left.
0029
0030 Smaller things:
0031 - i915_utils.h needs to be moved to the right places.
0032
0033 - dma_fence_work should be in drivers/dma-buf
0034
0035 - i915_mm.c should be moved to the right places. Some of the helpers also look a
0036 bit fishy:
0037
0038 https://lore.kernel.org/linux-mm/20210301083320.943079-1-hch@lst.de/
0039
0040 - tasklet helpers in i915_tasklet.h also look a bit misplaced and should
0041 probably be moved to tasklet headers.
