From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-15?Q?Christian_K=F6nig?= Subject: Re: [PATCH] drm: Add support for two-ended allocation, v2 Date: Wed, 02 Apr 2014 17:11:15 +0200 Message-ID: <533C2893.5030202@vodafone.de> References: <20140402120828.0140f283.cand@gmx.com> <533BEDB0.8090503@vodafone.de> <20140402175434.4ee3f283.cand@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by gabe.freedesktop.org (Postfix) with ESMTP id 7B4EC6EB8F for ; Wed, 2 Apr 2014 08:11:30 -0700 (PDT) In-Reply-To: <20140402175434.4ee3f283.cand@gmx.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Lauri Kasanen Cc: jglisse@redhat.com, Thomas Hellstrom , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org Am 02.04.2014 16:54, schrieb Lauri Kasanen: > On Wed, 02 Apr 2014 13:00:00 +0200 > Christian K=F6nig wrote: > >> Nice idea, but I wouldn't put the decision where to place the buffer >> into TTM based on it's size. >> >> Instead please make that a proper TTM placement flag because for example >> for VM page tables we want them to be at the end of VRAM, not because >> they are big (which they are anyway) but because they never accessed by >> the CPU. > I think there aren't many special cases like that, and they could > already be handled by setting the first and last pages for the bo? Nope, that would require the driver to find a certain position for the = buffer by itself. The placement flag should just move allocation from preferring the start = of the address space to preferring the end of it. What I wanted to note is that this way the driver could use this feature = in a much more flexible way, not only to change placement of buffers = based on the size, but also on other criteria as well (and yes I have = couple of use cases for this in mind). Additional to that you could also separate the patch into adding this = functionality and enabling it for radeon, which in the end will allow = people to easier bisect it in the case something is wrong. Apart from that the patch is a really nice piece of work, Christian. > > - Lauri