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