[Mesa-dev] r600g old design -> new design

[Jerome Glisse]

2010/9/29 Michel Dänzer <michel at 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