On 11/29/2012 03:15 AM, Marek Olšák wrote:
On Thu, Nov 29, 2012 at 12:44 AM, Alan Swanson <swanson@xxxxxxxxx> wrote:
On Wed, 2012-11-28 at 18:24 -0500, Jerome Glisse wrote:
On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom <thomas@xxxxxxxxxxxx> wrote:
On 11/28/2012 04:58 PM, j.glisse@xxxxxxxxx wrote:
From: Jerome Glisse <jglisse@xxxxxxxxxx>
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
So, a variation on John Carmack's recommendation from 2000 to use MRU,
not LRU, to avoid texture trashing.
Mar 07, 2000 - Virtualized video card local memory is The Right Thing.
http://floodyberry.com/carmack/johnc_plan_2000.html
In fact, this was last discussed in 2005 with a patch for a 1 second
stale texture eviction and I (still) wondered why a method it was never
implemented since it was an clear problem.
BTW we can send end-of-frame markers to the kernel, which could be
used to implement Carmack's algorithm.
Marek
It seems to me like Carmack's algorithm is quite specific to the case
where only a single GL client is running?
It also seems like it's designed around the fact that when eviction
takes place, all buffer objects will be idle. With a
reasonably filled graphics fifo / ring, blindly using MRU will cause the
GPU to run synchronized.
/Thomas
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
