TTM's role in score-based eviction
Lauri Kasanen
cand at gmx.com
Mon Dec 9 12:30:05 PST 2013
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.
- Lauri
More information about the dri-devel
mailing list