From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?windows-1252?Q?Christian_K=F6nig?= Subject: Re: [PATCH] drm/radeon: remove visible vram size limit on bo allocation Date: Thu, 17 Jul 2014 16:28:07 +0200 Message-ID: <53C7DD77.3090401@vodafone.de> References: <1405531594-25297-1-git-send-email-alexander.deucher@amd.com> <53C74AE7.30103@daenzer.net> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; 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 6D5506E695 for ; Thu, 17 Jul 2014 07:28:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by pegasos-out.vodafone.de (Rohrpostix1 Daemon) with ESMTP id D9D2D26088F for ; Thu, 17 Jul 2014 16:28:20 +0200 (CEST) Received: from pegasos-out.vodafone.de ([127.0.0.1]) by localhost (rohrpostix1.prod.vfnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCpoVUN0CFY5 for ; Thu, 17 Jul 2014 16:28:13 +0200 (CEST) In-Reply-To: <53C74AE7.30103@daenzer.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: =?windows-1252?Q?Michel_D=E4nzer?= , Alex Deucher Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org Am 17.07.2014 06:02, schrieb Michel D=E4nzer: > On 17.07.2014 02:26, Alex Deucher wrote: >> Now that fallback to gtt is fixed for cpu access, we can >> remove this limit. >> >> Signed-off-by: Alex Deucher >> --- >> drivers/gpu/drm/radeon/radeon_gem.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeo= n/radeon_gem.c >> index fdd189b..07a13c9 100644 >> --- a/drivers/gpu/drm/radeon/radeon_gem.c >> +++ b/drivers/gpu/drm/radeon/radeon_gem.c >> @@ -55,8 +55,11 @@ int radeon_gem_object_create(struct radeon_device *rd= ev, int size, >> alignment =3D PAGE_SIZE; >> } >> = >> - /* maximun bo size is the minimun btw visible vram and gtt size */ >> - max_size =3D min(rdev->mc.visible_vram_size, rdev->mc.gtt_size); >> + /* Maximum bo size is the gtt size since we use the gtt to handle >> + * vram to system pool migrations. We could probably remove this >> + * check altogether with a little additional work. >> + */ >> + max_size =3D rdev->mc.gtt_size; >> if (size > max_size) { >> DRM_DEBUG("Allocation size %dMb bigger than %ldMb limit\n", >> size >> 20, max_size >> 20); > A BO of size rdev->mc.gtt_size can never actually be bound to GTT, > because we have some pinned BOs in there. I think it's a bit > disingenuous to let userspace allocate a BO that can never actually be > used by the GPU. :) > > The hack I attached to > https://bugs.freedesktop.org/show_bug.cgi?id=3D78717 has a start for > dealing with that. I was running that patch for a while and didn't > notice any bad effects from it. Haven't looked at the patch yet, but can't we just go over all existing = allocations on PIN and figure out the largest free area and save that = value? I mean pinning of GTT memory happens rarely and mostly on system = startup. Christian.