-------- 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). And as you know, the AGPGART driver does a cache flush for the allocated resp. inserted AGP memory. > The normal ring and IB tests are probably too simple to catch that kind > of problem. I don't suppose higher transfer rates work any better? :) I Well AGP 2x works, but that doesn't make a difference. I just used AGP 1x for testing, because AGP 2x fails after a soft reboot (looks like some PLL is out of lock). Good hardware, right? ;-) > 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. 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? Does the CPU always read directly from VRAM, if it can't access the aperture or does the DRM layer instruct the GPU to write the data back to system memory? Thanks, Gerhard -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ------------------------------------------------------------------------------ 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
