| 1234567891011121314151617181920212223242526272829303132333435363738394041 |
- 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/[email protected]/
- - tasklet helpers in i915_tasklet.h also look a bit misplaced and should
- probably be moved to tasklet headers.
|
