-------- Original-Nachricht --------
> Datum: Tue, 15 Dec 2009 15:13:33 +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 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
> > 
> > > 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.
Just to clarify, I meant a PCI memory _space_ is usually mapped
non-cacheable on powerpc. Otherwise I fully agree.

> > 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.
Okay, that's something I didn't consider.

> > > I don't suppose higher transfer rates work any better? :) I
> > Well AGP 2x works, [...]
> 
> 'Works' as in passes radeon.test=1?
No, unfortunately the test also fails with AGP 2x. "Works" as in "system
doesn't lock up anymore" and only "ring and ib test" passed.

> > > 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?
:)
Well, I didn't verify that this happens on my machine. But I'm sure it
is the case with memory allocated by the generic AGP layer functions (as
far as I can see they allocate cacheable memory), as the bridge's snoop
logic is buggy. As you say, it must be some sort of coherency issue.

> > 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.
And this memory is mapped uncacheable by radeon/TTM? Doesn't that limit
the maximum usable memory for radeon/TTM to the vmalloc space?

> > 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.
Okay.

> 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)

Well, I'm a little bit confused now. :) I would expect the test to pass
in AGPGART mode, if radeon/TTM maps the memory as uncacheable and the addresses 
of the pages marked as uncacheable are inserted into the GATT
or the AGPGART driver.

Thanks for your patience!

best regards,

Gerhard

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to