From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-15?Q?Christian_K=F6nig?= Subject: Re: [PATCH] drm/radeon: TTM must be init with cpu-visible VRAM Date: Fri, 28 Feb 2014 16:43:54 +0100 Message-ID: <5310AEBA.8080303@vodafone.de> References: <20140227233848.78fffa58.cand@gmx.com> <531058BB.6050100@vodafone.de> <20140228173039.8192741d.cand@gmx.com> <20140228173624.3f7b804c.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 40811FA56C for ; Fri, 28 Feb 2014 07:44:08 -0800 (PST) In-Reply-To: <20140228173624.3f7b804c.cand@gmx.com> 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: Lauri Kasanen Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org Am 28.02.2014 16:36, schrieb Lauri Kasanen: > On Fri, 28 Feb 2014 17:30:39 +0200 > Lauri Kasanen wrote: > >> On Fri, 28 Feb 2014 10:36:59 +0100 >> Christian K=F6nig wrote: >> >>> Am 27.02.2014 22:38, schrieb Lauri Kasanen: >>>> Without this, a bo may get created in the cpu-inaccessible vram. >>>> Before the CP engines get setup, all copies are done via cpu memcpy. >>>> >>>> This means that the cpu tries to read from inaccessible memory, fails, >>>> and the radeon module proceeds to disable acceleration. >>>> >>>> Doing this has no downsides, as the real VRAM size gets set as soon as= the >>>> CP engines get init. >>>> >>>> This is a candidate for 3.14 fixes. >>> This should be unnecessary, since TTM gets initialized only seeing the >>> visible VRAM and later on radeon_ttm_set_active_vram_size gets called to >>> increase the limit. >>> >>> If this isn't the case any more we should figure out why instead of >>> working around it like this. >> Negative, TTM gets initialized with real_vram just a few lines above >> this patch, not visible_vram. > git blame shows 7a50f01a from 2009, "drm/radeon/kms: vram sizing on > certain r100 chips needs workaround." by Dave Airlie. > > So the TTM VRAM init has been wrong for five years, and only worked by > accident because until now all allocations were done bottom-up. Yeah, just came to the same conclusion. We probably never hit the case = in the last five years because we don't really access the memory before = we start the copy ring. Please fix ttm_bo_init_mm to use rdev->mc.visible_vram_size instead. That allocations are made bottom-up is relied upon in a couple of other = cases as well, the stolen VGA memory and the UVD firmware handling for = example. Christian. > - Lauri