42 lines
1.8 KiB
Plaintext
42 lines
1.8 KiB
Plaintext
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_tasklet.h also look a bit misplaced and should
|
|
probably be moved to tasklet headers.
|