[PATCH 2/2] radeon: attempt to fix active vram since 93225b0d7bc030f4a93165347a65893685822d70

[Dave Airlie]

>> This can spuriously limit the BO to active_vram_size in GTT again.
>
> On second thought, I don't understand why this would be necessary /
> helpful at all. If active_vram_size is the maximum amount of VRAM that
> should ever be used anywhere (as opposed to the maximum amount visible
> to the CPU, which I was thinking of before), why is the VRAM
> ttm_mem_type_manager size field larger than that in the first place?

It's a bit of a pain but we don't know we need to limit active VRAM
until accel fails later on by which time we've already set the ttm
manager up, my current thinking is to make fpfn/lpfn part of the per
mem type placement or to force pin a large object in the second chunk
of VRAM though i'm not liking that at this point to fix the
regression.

Dave

>
>
> --
> Earthling Michel Dänzer           |                http://www.vmware.com
> Libre software enthusiast         |          Debian, X and DRI developer
>