Re: Testing an AGPGART driver with radeon.test=1
On Tue, 2009-12-15 at 22:26 +0100, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Tue, 2009-12-15 at 13:37 +0100, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net 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. I don't think we've ever used cacheable memory with any AGP bridge in Linux. 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? Yes. Doesn't that limit the maximum usable memory for radeon/TTM to the vmalloc space? That could only be relevant for kernel mappings. The kernel only maps buffer object (BO) memory when/while necessary, which usually isn't the case. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- 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
Re: Testing an AGPGART driver with radeon.test=1
Original-Nachricht Datum: Wed, 16 Dec 2009 10:54:15 +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 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? Yes. Well, in short I fail to see now how radeon/TTM allocates and maps the memory used for the test into the AGP GART resp. which functions are called the way down from the radeon driver to the AGPGART driver (radeon-TTM-(DRM?)-AGP). I guess I should ask Google for some TTM/DRM documentation. :) Doesn't that limit the maximum usable memory for radeon/TTM to the vmalloc space? That could only be relevant for kernel mappings. The kernel only maps buffer object (BO) memory when/while necessary, which usually isn't the case. Okay. Thanks, Gerhard -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02 -- 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
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 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
Re: Testing an AGPGART driver with radeon.test=1
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
Testing an AGPGART driver with radeon.test=1
Hi,
A long time ago I was working on an AGPGART driver for my PPC machine,
but couldn't get it working due to missing datasheet, etc. Now I started
working on it again, as Radeon KMS works well on my machine so far and I
also rediscovered an old binary-only AGPGART driver for which objdump
revealed some interesting information.
Well, the current driver code is basically a copy of the UniNorth AGPGART
driver. The driver initializes fine, as the excerpt below shows:
calling agp_init+0x0/0x54 @ 1
Linux agpgart interface v0.103
initcall agp_init+0x0/0x54 returned 0 after 2749 usecs
calling agp_articias_init+0x0/0x58 @ 1
agpgart-articias :00:00.0: MAI Logic Articia S chipset
agpgart-articias :00:00.0: configuring for size idx: 1
agpgart-articias :00:00.0: AGP aperture is 4M @ 0xc000
initcall agp_articias_init+0x0/0x58 returned 0 after 19494 usecs
calling drm_core_init+0x0/0x158 @ 1
[drm] Initialized drm 1.1.0 20060810
initcall drm_core_init+0x0/0x158 returned 0 after 4526 usecs
calling ttm_init+0x0/0x8c @ 1
initcall ttm_init+0x0/0x8c returned 0 after 1170 usecs
calling radeon_init+0x0/0x100 @ 1
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
[drm] radeon: Initializing kernel modesetting.
[drm] register mmio base: 0x8800
[drm] register mmio size: 65536
[drm] GPU reset succeed (RBBM_STATUS=0x0140)
[drm] Generation 2 PCI interface, using max accessible memory
[drm] AGP mode requested: 1
agpgart-articias :00:00.0: AGP 1.0 bridge
agpgart-articias :00:00.0: putting AGP V2 device into 1x mode
radeon :01:00.0: putting AGP V2 device into 1x mode
[drm] radeon: VRAM 128M
[drm] radeon: VRAM from 0x to 0x07FF
[drm] radeon: GTT 4M
[drm] radeon: GTT from 0xC000 to 0xC03F
[drm] radeon: irq initialized.
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 128bits DDR
[TTM] Zone kernel: Available graphics memory: 377416 kiB.
[TTM] Zone highmem: Available graphics memory: 770632 kiB.
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 4M of GTT memory ready.
[drm] radeon: cp idle (0x02000603)
[drm] Loading R200 Microcode
platform radeon_cp.0: firmware: using built-in firmware radeon/R200_cp.bin
agpgart-articias :00:00.0: TLB flush!
[drm] radeon: ring at 0xC000
[drm] ring test succeeded in 0 usecs
agpgart-articias :00:00.0: TLB flush!
agpgart-articias :00:00.0: TLB flush!
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
[drm] DFP table revision: 3
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] VGA
[drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[drm] Encoders:
[drm] CRT1: INTERNAL_DAC1
[drm] Connector 1:
[drm] DVI-I
[drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[drm] Encoders:
[drm] CRT2: INTERNAL_DAC2
[drm] DFP1: INTERNAL_TMDS1
[drm] fb mappable at 0x8004
[drm] vram apper at 0x8000
[drm] size 768
[drm] fb depth is 24
[drm]pitch is 6400
[drm] TMDS-12: set mode 1600x1200 24
Console: switching to colour frame buffer device 200x75
fb0: radeondrmfb frame buffer device
registered panic notifier
[drm] Initialized radeon 2.0.0 20080528 for :01:00.0 on minor 0
initcall radeon_init+0x0/0x100 returned 0 after 635215 usecs
Judging from what the log says, I would expect that the radeon driver
can make use of the AGP aperture (as the the ring and ib test succeed -
is this assumption correct?).
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?
Thanks!
best regards,
Gerhard
PS: Please put me on CC:.
articias-agp.c:
/*
* Articia S AGPGART routines.
*/
#include linux/module.h
#include linux/pci.h
#include linux/init.h
#include linux/pagemap.h
#include linux/vmalloc.h
#include linux/agp_backend.h
#include agp.h
#define ARTICIAS_GARTCTRL 0x58/* bit 6 - GART enable */
#define ARTICIAS_APSIZE 0x59/* bit 2:0 - aperture size */
#define ARTICIAS_TLBCTRL0xe0/* bit 5 - TLB flush */
#define ARTICIAS_GATTBASE 0x58/* 31:12 GATT base address */
static int articias_fetch_size(void)
{
int i;
u8 temp;
struct aper_size_info_8 *values;
values = A_SIZE_8(agp_bridge-driver-aperture_sizes);
pci_read_config_byte(agp_bridge-dev, ARTICIAS_APSIZE, temp);
temp = 0x07;
for (i = 0; i agp_bridge-driver-num_aperture_sizes; i++) {
if (temp == values[i].size_value) {
agp_bridge-previous_size =
agp_bridge-current_size = (void *)
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. 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 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. Hope this helps, -- 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
