On Tue, 2009-12-15 at 13:37 +0100, Gerhard Pircher wrote: > -------- Original-Nachricht -------- > > Datum: Tue, 15 Dec 2009 00:01:50 +0100 > > Von: "Michel Dänzer" <mic...@daenzer.net> > > An: Gerhard Pircher <gerhard_pirc...@gmx.net> > > CC: dri-devel@lists.sourceforge.net > > Betreff: Re: Testing an AGPGART driver with radeon.test=1 > > > On Mon, 2009-12-14 at 23:21 +0100, Gerhard Pircher wrote: > > > > > > Next I booted the kernel with radeon.test=1 and this test fails > > > immediately with a message like this: > > > > > > [drm:radeon_test_moves] *ERROR* Incorrect GTT->VRAM copy 0: Got > > > 0xf14a88f0, expected 0xf14a6680 (GTT map 0xf14a6000-0xf15a6000) > > > > > > A different aperture size doesn't make any difference. However the > > > test works in PCIGART mode. > > > Now I wonder what the problem could be, as I don't have a clue about > > > the radeon/DRM code. Can somebody explain me, how the test works and > > > what the error message means for the AGPGART driver? > > > > The test output is a little cryptic and could be improved... > > > > The failing phase of the test fills the GTT memory with the kernel > > virtual addresses of itself, copies it to VRAM with the GPU, reads it > > back again with the CPU and verifies the contents. It read back > > 0xf14a88f0 when it expected 0xf14a6680, so the latter is the kernel > > virtual address of the first word which wasn't copied correctly. > > Subtracting the start of the GTT map (0xf14a6000) yields that only 1664 > > bytes (+ 2, as the first two bytes of the incorrect word are correct) > > were copied correctly. > Thanks, now it makes sense to me, but raises some other questions. :) > When VRAM is the graphics card's onboard memory, then the CPU should get > correct data, as PCI memory is usually mapped non-cacheable (I hope > that is true for prefetchable PCI memory, too).
Yes. There's various caches on the GPU as well, but if those were the problem here, I'd expect it to affect PCI GART as well. > And as you know, the AGPGART driver does a cache flush for the > allocated resp. inserted AGP memory. Right, though that won't happen between all CPU writes and GPU reads in general, though it may always be the case with this test. > > I don't suppose higher transfer rates work any better? :) I > Well AGP 2x works, [...] 'Works' as in passes radeon.test=1? > > guess there could be many possible causes for the problem, but the most > > likely seems some kind of coherency issue between the CPU writes and GPU > > reads. > Well, the northbridge doesn't guarantee coherence. So I'm sure you're > correct. Although I can only see the problem ATM, when the GPU writes > data to system memory, which is later read by the CPU. What exactly does 'can see' mean? > That should fail, because the cache isn't invalidated. I'm sure I'm missing > something here. > > I guess the memory used for this test is allocated by the AGP layer and > not by the radeon driver? No, it's allocated by radeon/TTM. > Does the CPU always read directly from VRAM, Not 'always' in general but for this test, yes. > if it can't access the aperture [...] If by 'can't access the aperture' you're referring to the linear AGP aperture bot being available in the CPU address space, VRAM access has nothing to do with that (or AGP in general). I doubt the problem is related to that at all. radeon/TTM just map the underlying RAM pages directly in that case, uncacheable. FWIW, this is all working fine for me with the UniNorth AGP bridge in my PowerBook. (Well, for some reason KMS still only works reliably with 1x, whereas non-KMS worked with 4x, but that probably doesn't matter all that much overall) -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
