TTM's role in score-based eviction

[Marek Olšák]

On Mon, Dec 9, 2013 at 9:30 PM, Lauri Kasanen <cand at gmx.com> wrote:
> On Mon, 9 Dec 2013 20:28:21 +0100
> Marek Olšák <maraeo at gmail.com> wrote:
>
> Hi,
>
>> 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.
>
> I think this would result in sub-optimal behavior with one client, but
> a workload larger than VRAM. If everything is needed in one frame, then
> this logic would almost randomly decide what gets to stay.
>
>> 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.
>
> Thanks, this info will be useful.
>
> Note that the hotness calculation will be in userspace, as only there
> are the necessary counters available. So the finished hotness score
> will be passed to the kernel, instead of sending all the necessary data
> there. Ought to be less context switches that way.

This sounds good, but you will also need to update the DDX for
everything up to and including Cayman. Hopefully the DDX doesn't emit
IBs outside of glamor on Southern Islands and later chips.

Marek