TTM's role in score-based eviction

[Marek Olšák]

Hi Lauri,

FYI, since the userspace driver sends end-of-frame markers to the
kernel, the radeon kernel driver knows the current frame number and it
can also save the frame number of the last use of each buffer. We
should definitely use that to measure the buffer hotness, or just
prevent eviction if the buffer was used recently (the last 2 or 3
frames) and you can drop the hotness calculations entirely.

Also, MSAA buffers and depth buffers should have higher probability of
being placed in VRAM than other buffers, because their placement has
higher impact on performance. They also tend to contain auxiliary data
which significantly improve performance, like fast clear data, MSAA
fragment coverage data, and hierarchical depth and stencil data. We
can add a new ioctl which sets buffer usage flags.

One can say the same thing about colorbuffers too, but there's no easy
way to distinguish between a colorbuffer and an ordinary texture which
isn't used as a colorbuffer but is blitted from time to time.

Marek

On Thu, Dec 5, 2013 at 10:36 AM, Lauri Kasanen <cand at gmx.com> wrote:
> Hi list, Thomas,
>
> I will be investigating the use of a hotness score for each bo, to
> replace the ping-pong causing LRU eviction in radeon*.
>
> The goal is to put all bos that fit in VRAM there, in order of hotness;
> a new bo should only be placed there if its hotness score is greater
> than the lowest VRAM bo's. Then the lowest-hotness-bos in
> VRAM should be evicted until the new bo fits. This should result in a
> more stable set with less ping-pong.
>
> Jerome advised that the bo placement should be done entirely outside
> TTM. As I'm not (yet) too familiar with that side of the kernel, what is
> the opinion of TTM folks?
>
> - Lauri
>
> * github.com/clbr/jamkthesis
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel