From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lauri Kasanen Subject: Re: TTM's role in score-based eviction Date: Mon, 9 Dec 2013 22:30:05 +0200 Message-ID: <20131209223005.a33d4312.cand@gmx.com> References: <20131205113658.52c84991.cand@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by gabe.freedesktop.org (Postfix) with ESMTP id 62595FAEE9 for ; Mon, 9 Dec 2013 12:29:25 -0800 (PST) Received: from Valinor ([84.248.177.169]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MZU7V-1W99u40ISz-00LHaH for ; Mon, 09 Dec 2013 21:29:17 +0100 In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: Marek =?ISO-8859-15?Q?Ol=A8=E1k?= Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org On Mon, 9 Dec 2013 20:28:21 +0100 Marek Ol=A8=E1k 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