Plan: BO move throttling for visible VRAM evictions

Marek Olšák maraeo at
Wed May 17 12:35:58 UTC 2017

On May 16, 2017 3:57 AM, "Michel Dänzer" <michel at> wrote:

On 15/05/17 07:11 PM, Marek Olšák wrote:
> On May 15, 2017 4:29 AM, "Michel Dänzer" <michel at
> <mailto:michel at>> wrote:
>     I think the next step should be to make radeonsi keep track of how
>     VRAM it's trying to use that's expected to be accessed by the CPU, and
>     to use GTT instead when that exceeds a threshold (probably derived
>     vram_vis_size).
> That's difficult to estimate. There are apps with 600MB of mapped VRAM
> and don't experience any performance issues. And some apps with 300MB of
> mapped VRAM do. It only depends on the CPU access pattern, not what
> radeonsi sees.

What I mean is keeping track of the total size of resources which have
RADEON_DOMAIN_VRAM and RADEON_FLAG_CPU_ACCESS set, and if it exceeds a
threshold, create new ones having those flags in GTT instead. Even
though this might not be strictly necessary with amdgpu in the long run,
it probably is for radeon anyway, and in the short term it might help
even with amdgpu.

That might hurt us more than it can help. All mappable buffers have the CPU
access flag set, but many of them are immutable.

The only place where this can be handled​ is the kernel. Even if it's as
simple as: if (bo->numcpufaults > 10) domain = GTT_WC;


Earthling Michel Dänzer               |     
Libre software enthusiast             |             Mesa and X developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amd-gfx mailing list