All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lauri Kasanen <cand@gmx.com>
To: "Marek Olšák" <maraeo@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: TTM's role in score-based eviction
Date: Mon, 9 Dec 2013 22:30:05 +0200	[thread overview]
Message-ID: <20131209223005.a33d4312.cand@gmx.com> (raw)
In-Reply-To: <CAAxE2A69NHudvZYUGcEg+5gHhR+vbqTQmpxZQScOapsgNfdcJg@mail.gmail.com>

On Mon, 9 Dec 2013 20:28:21 +0100
Marek Olšák <maraeo@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

  reply	other threads:[~2013-12-09 20:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-05  9:36 TTM's role in score-based eviction Lauri Kasanen
2013-12-05 10:26 ` Thomas Hellstrom
2013-12-05 15:49   ` Jerome Glisse
2013-12-05 16:22     ` Maarten Lankhorst
2013-12-05 16:45       ` Jerome Glisse
2013-12-09 17:28         ` Daniel Vetter
2013-12-09 19:32           ` Thomas Hellstrom
2013-12-09 19:28 ` Marek Olšák
2013-12-09 20:30   ` Lauri Kasanen [this message]
2013-12-09 22:45     ` Marek Olšák
2013-12-10  0:49       ` Michel Dänzer
2013-12-10 11:03         ` Maarten Lankhorst
2013-12-11  3:04           ` Michel Dänzer
2013-12-11  7:57             ` Maarten Lankhorst
2013-12-11  8:36               ` Thomas Hellstrom
2013-12-11 11:35             ` Lauri Kasanen
2013-12-11 14:46               ` Thomas Hellstrom
2013-12-11 16:29                 ` Lauri Kasanen
2013-12-10 11:14         ` Marek Olšák
2013-12-10 11:59       ` Lauri Kasanen
2013-12-10 13:18         ` Marek Olšák

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131209223005.a33d4312.cand@gmx.com \
    --to=cand@gmx.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=maraeo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.