[PATCH 2/2] drm/vram-helper: Alternate between bottom-up and top-down placement
Gerd Hoffmann
kraxel at redhat.com
Wed Apr 29 07:25:00 UTC 2020
Hi,
> It's not that easy. Current cursors n ast are statically allocated. As
> soon as you add dynamic cursors into the mix, you'd get OOMs.
Well, with the split you can simply allocate dynamic cursors with
top-bottom to keep them out of the way. It's not 100% perfect, the area
where the cursors are allocated from has a bit less free vram, so the
split effectively isn't 50/50 but more like 49/51. But hey, still alot
better than what we have today.
With two static cursors you can allocate one from TT_VRAM and one from
TT_PRIV so the remaining free vram is the same in both regions.
> If the framebuffer BO goes into VRAM and the cursor BO goes into PRIV,
> pinning the next framebuffer BO during a pageflip would send it to
> VRAM.
Oh, seems my idea outline was a bit to short. The plan is *not* to
alternate between VRAM and PRIV on allocations. The plan is to add both
PRIV and VRAM to the placement array when pinning the framebuffer.
ttm can simply place the framebuffers as it pleases and where it wants.
Due to the split it can't do a big blocking allocation in the middle
of vram though.
If you are going to pageflip you should have one framebuffer already
pinned (the one currently displayed). If that happens to live TT_VRAM
ttm should be able to make room in TT_PRIV to pin the new framebuffer
you want pageflip to, and visa-versa.
ttm will only evict unpinned BOs if needed, when running with smaller
framebuffers ttm will happily keep more than two framebuffers in vram.
All fully automatic without vram helpers having to pay much attention
to the allocation strategy.
> I'm preparing v2 of this patch set. It'll get static cursors out of the
> way and make the feature opt-in.
I think with the split model there is no need to make that optional.
cheers,
Gerd
More information about the dri-devel
mailing list