From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Deucher Subject: Re: [RFC PATCH v2] Utilize the PCI API in the TTM framework. Date: Tue, 11 Jan 2011 13:12:57 -0500 Message-ID: References: <1294420304-24811-1-git-send-email-konrad.wilk@oracle.com> <4D2B16F3.1070105@shipmail.org> <20110110152135.GA9732@dumpdata.com> <4D2B2CC1.2050203@shipmail.org> <20110110164519.GA27066@dumpdata.com> <4D2B70FB.3000504@shipmail.org> <20110111155545.GD10897@dumpdata.com> <20110111165953.GI10897@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20110111165953.GI10897@dumpdata.com> Sender: linux-kernel-owner@vger.kernel.org To: Konrad Rzeszutek Wilk Cc: Thomas Hellstrom , konrad@darnok.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Tue, Jan 11, 2011 at 11:59 AM, Konrad Rzeszutek Wilk wrote: >> >> Another thing that I was thinking of is what happens if you have = a >> >> huge gart and allocate a lot of coherent memory. Could that >> >> potentially exhaust IOMMU resources? >> > >> > >> > >> > So the GART is in the PCI space in one of the BARs of the device r= ight? >> > (We are talking about the discrete card GART, not the poor man AMD= IOMMU?) >> > The PCI space is under the 4GB, so it would be considered coherent= by >> > definition. >> >> GART is not a PCI BAR; it's just a remapper for system pages. =A0On >> radeon GPUs at least there is a memory controller with 3 programmabl= e >> apertures: vram, internal gart, and agp gart. =A0You can map these > > To access it, ie, to program it, you would need to access the PCIe ca= rd > MMIO regions, right? So that would be considered in PCI BAR space? yes, you need access to the mmio aperture to configure the gpu. I was thinking you mean something akin the the framebuffer BAR only for gart space which is not the case. > >> resources whereever you want in the GPU's address space and then the >> memory controller takes care of the translation to off-board resourc= es >> like gart pages. =A0On chip memory clients (display controllers, tex= ture >> blocks, render blocks, etc.) write to internal GPU addresses. =A0The= GPU >> has it's own direct connection to vram, so that's not an issue. =A0F= or >> AGP, the GPU specifies aperture base and size, and you point it to t= he >> bus address of gart aperture provided by the northbridge's AGP >> controller. =A0For internal gart, the GPU has a page table stored in > > I think we are just talking about the GART on the GPU, not the old AG= P > GART. Ok. I just mentioned it for completeness. > >> either vram or uncached system memory depending on the asic. =A0It >> provides a contiguous linear aperture to GPU clients and the memory >> controller translates the transactions to the backing pages via the >> pagetable. > > So I think I misunderstood what is meant by 'huge gart'. That sounds > like linear address space provided by GPU. And hooking up a lot of co= herent > memory (so System RAM) to that linear address space would be no diffe= rent that what > is currently being done. When you allocate memory using page_alloc(GF= P_DMA32) > and hook up that memory to the linear space you exhaust the same amou= nt of > ZONE_DMA32 memory as if you were to use the PCI API. It comes from th= e same > pool, except that doing it from the PCI API gets you the bus address = right > away. > In this case GPU clients refers to the hw blocks on the GPU; they are the ones that see the contiguous linear aperture. From the application's perspective, gart memory looks like any other pages. Alex