On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom <thomas at shipmail.org> wrote: > On 11/28/2012 04:58 PM, j.glisse at gmail.com wrote: >> >> From: Jerome Glisse <jglisse at redhat.com> >> >> This patch add a minimum residency time configurable for each memory >> pool (VRAM, GTT, ...). Intention is to avoid having a lot of memory >> eviction from VRAM up to a point where the GPU pretty much spend all >> it's time moving things in and out. > > > This patch seems odd to me. > > It seems the net effect is to refuse evictions from VRAM and make buffers go > somewhere else, and that makes things faster? > > Why don't they go there in the first place instead of trying to force them > into VRAM, > when VRAM is full? > > /Thomas
It's mostly a side effect of cs and validating with each cs, if boA is in cs1 and not in cs2 and boB is in cs1 but not in cs2 than boA could be evicted by cs2 and boB moved in, if next cs ie cs3 is like cs1 then boA move back again and boB is evicted, then you get cs4 which reference boB but not boA, boA get evicted and boB move in ... So ttm just spend its time doing eviction but he doing so because it's ask by the driver to do so. Note that what is costly there is not the bo move in itself but the page allocation. I propose this patch to put a boundary on bo eviction frequency, i thought it might help other driver, if you set the residency time to 0 you get the current behavior, if you don't you enforce a minimum residency time which helps driver like radeon. Of course a proper fix to the bo eviction for radeon has to be in radeon code and is mostly an overhaul of how we validate bo. But i still believe that this patch has value in itself by allowing driver to put a boundary on buffer movement frequency. Cheers, Jerome
