2010/9/29 Michel Dänzer <mic...@daenzer.net>: > On Mit, 2010-09-29 at 11:49 +0100, Keith Whitwell wrote: >> On Wed, 2010-09-29 at 03:35 -0700, Michel Dänzer wrote: >> > On Die, 2010-09-28 at 11:40 -0400, Jerome Glisse wrote: >> > > >> > > - use score for placing bo, bo placement will be recorded in bo >> > > structure and >> > > each time a state is bind bo score will be updated (bo bound as >> > > framebuffer >> > > will get their score for placing into vram increase while bo bound as >> > > small >> > > vertex buffer will endup in GTT, also anytime a bo is mapped for >> > > transfer for >> > > CPU read its score for GTT placement increase thus bo that are often >> > > updated >> > > by CPU will more likely place into GTT) >> > >> > Beware that the EXA 'classic' scheme originally (with the 'greedy' and >> > 'smart' heuristics) used a score like that to determine whether a pixmap >> > should reside in VRAM or system memory, and it could result in quite >> > erratic / inconsistent / unreproducible behaviour when the score hovered >> > around the threshold. It could make fixing or even reproducing problems >> > harder than it is already. >> >> Did trying some sort of hysteresis - eg. having different thresholds for >> upload vs. download help? > > There actually already is a hysteresis — I forgot about that, thanks for > reminding me. I never tried playing with the threshold values, don't > know if anyone did. > >
Yeah i do remember the issue with the ddx, i hope to be able to come up with somethings that won't change its mind every cs (ie once a bo is assigned to GTT or VRAM it will stay there for a bit before being re-evaluated to move to other domain). Anyway if it's catastrophic it will be self contained enough that it should be easy to test other way to be smart about bo placement (if we could ever be smart about it :)) Cheers, Jerome _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
