On 28.10.2014 20:10, Daniel Vetter wrote:
On Tue, Oct 28, 2014 at 06:35:04PM +0900, Michel Dänzer wrote:
From: Michel Dänzer <michel.daenzer@xxxxxxx>
DRM_MM_SEARCH_BEST gets the smallest hole which can fit the BO. That seems
against the idea of TTM_PL_FLAG_TOPDOWN:
* The smallest hole may be in the overall bottom of the area
* If the hole isn't much larger than the BO, it doesn't make much
difference whether the BO is placed at the bottom or at the top of the
hole
Signed-off-by: Michel Dänzer <michel.daenzer@xxxxxxx>
tbh I think SEARCH_BEST is pretty much always a bad idea - it rips apart
allocations from the same execbuf, and usually those get recycled around
the same time. Which means you'll just fragment your mm even more if you
try to find the best hole instead of just picking one and the stuffing the
entire execbuf into it. So imo we might as well just kill it.
Sent out a new patch 4 which nukes it.
Another one that I've advertised a bunch of times already is the scan
roaster in drm_mm.c: Currently ttm just evicts until there's a big enough
hole, which is fairly awful if you have quasi-segmented memory like with
top-down/bottom-up schemes and different ranges for different units. With
the roaster you just walk the lru and build up potential holes until
there's a suitable one, and then only evict those buffers. Which means if
you have a certain range of memory under very high pressure (e.g. the 256M
which uvd can use or whatever it is), then you wont thrash all the other
vram too.
I recently made some changes in TTM and radeon to alleviate that
particular issue, but the scan roaster does sound useful. Unfortunately,
modifying TTM to use it is a bit too involved for me right now, any
volunteers?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
