Very nice. I'm looking forward to this for KFD as well. One question: Will it be possible to share these split BOs as dmabufs? Regards, Felix On 16-08-16 11:27 AM, Christian König wrote: > Hi Marek, > > I'm already working on this. > > My current approach is to use a custom BO manager for VRAM with TTM > and so split allocations into chunks of 4MB. > > Large BOs are still swapped out as one, but it makes it much more > likely to that you can allocate 1/2 of VRAM as one buffer. > > Give me till the end of the week to finish this and then we can test > if that's sufficient or if we need to do more. > > Regards, > Christian. > > Am 16.08.2016 um 16:33 schrieb Marek Olšák: >> Hi, >> >> I'm seeing random temporary freezes (up to 2 seconds) under memory >> pressure. Before I describe the exact circumstances, I'd like to say >> that this is a serious issue affecting playability of certain AAA >> Linux games. >> >> In order to reproduce this, an application should: >> - allocate a few very large buffers (256-512 MB per buffer) >> - allocate more memory than there is available VRAM. The issue also >> occurs (but at a lower frequency) if the app needs only 80% of VRAM. >> >> Example: ttm_bo_validate needs to migrate a 512 MB buffer. The total >> size of moved memory for that call can be as high as 1.5 GB. This is >> always followed by a big temporary drop in VRAM usage. >> >> The game I'm testing needs 3.4 GB of VRAM. >> >> Setups: >> Tonga - 2 GB: It's nearly unplayable, because freezes occur too often. >> Fiji - 4 GB: There is one freeze at the beginning (which is annoying >> too), after that it's smooth. >> >> So even 4 GB is not enough. >> >> Workarounds: >> - Split buffers into smaller pieces in the kernel. It's not necessary >> to manage memory at page granularity (64KB). Splitting buffers into >> 16MB-large pieces might not be optimal but it would be a significant >> improvement. >> - Or do the same in Mesa. This would prevent inter-process and >> inter-API buffer sharing for split buffers (DRI, OpenCL), but we would >> at least verify how much the situation improves. >> >> Other issues sharing the same cause: >> - Allocations requesting 1/3 or more VRAM have a high chance of >> failing. It's generally not possible to allocate 1/2 or more VRAM as >> one buffer. >> >> Comments welcome, >> >> Marek >> _______________________________________________ >> amd-gfx mailing list >> amd-gfx at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > > _______________________________________________ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
