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 at amd.com> >> >> 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 at amd.com> > > 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