12.04 PPC G3 R128 AGP Mesa DRI and Modelines

[str8bs]

Thanks for taking a look.

Regarding PRAM and Modelines:
You were right. I did not reset PRAM, but confirmed that changing geometry settings in OSX changed my display in Linux. Since I'm dual booting OSX 10.4, I will adjust there first and then "tweak" modelines until I get there. Sidenote: stumbled on "apt-get install videogen" and find it a lot more useful than cvt for this purpose.

Regarding AGP vs. PCIMode:
A major cocern for me is the ability to use system RAM, and I may have confirmed AGPSize gets ignored when ForcePCIMode is used. My thinking that RAM is relatively cheap and easy for these machines. VideoRAM - not gonna happen. Could be really useful on the ones with 4 or 6 MB of VRAM.

If I add Option "AGPSize" "32" to the xorg.conf in the first post, this is the major difference I was hoping to fix more so than just FPS.

This is from 3.2.0-23 (Lubuntu) but is the same as 3.2.0-26

PCIMode
[   930.139] (II) R128(0): Using 8 MB AGP aperture
[   930.140] (II) R128(0): Using 1 MB for the ring buffer
[   930.140] (II) R128(0): Using 2 MB for vertex/indirect buffers
[   930.140] (II) R128(0): Using 1 MB for AGP textures

AGP Mode (and unusable due to CCEtimeouts)
[    34.422] (II) R128(0): Using 32 MB AGP aperture
[    34.422] (II) R128(0): Using 1 MB for the ring buffer
[    34.422] (II) R128(0): Using 2 MB for vertex/indirect buffers
[    34.422] (II) R128(0): Using 29 MB for AGP textures

Putting uninorth_agp in modules didn't change things. drm.debug didn't yield anything obvious to me.

I still think the significant error is

aty128fb 0000:00:10.0: putting AGP V2 device into 0x mode

Agreed, and I don't understand this either:

dmesg | grep -i vga
[    0.047384] vgaarb: loaded
[   32.545041] vgaarb: this pci device is not a vga device
[   33.354151] vgaarb: this pci device is not a vga device
[   33.964274] agpgart: Couldn't find an AGP VGA controller.

I still will try the kernel compile to see if it yields more performance. But, if it does force PCI mode, then we still lose use of system RAM. (I think.)

I realize DRI for R128 is no longer officially supported, but would a bug report be warranted? Even if a user isn't downgrading mesa, the initial install appears as "hung" system since DRI is enabled by default.

The attached has detailed logs with and without PCIMode in 3.2.0-23 if anyone wants to take a closer look.
Thanks

[tormod]

aty128fb 0000:00:10.0: putting AGP V2 device into 0x mode

I have actually seen this other places (savage/x86). I think this is a bug in the kernel agp driver or in the agp bridge. It tries to set a value (the default value, 1?) that the card does not say it can use, and it ends up with "0". This is not the same 0 as in agpmode=0 which is meant to disable AGP. I proposed a kernel patch, but no developer wants to touch this old agp stuff even with a long stick.

Agreed, and I don't understand this either:

dmesg | grep -i vga
[    0.047384] vgaarb: loaded
[   32.545041] vgaarb: this pci device is not a vga device
[   33.354151] vgaarb: this pci device is not a vga device
[   33.964274] agpgart: Couldn't find an AGP VGA controller.

I still will try the kernel compile to see if it yields more performance. But, if it does force PCI mode, then we still lose use of system RAM. (I think.)

I realize DRI for R128 is no longer officially supported, but would a bug report be warranted? Even if a user isn't downgrading mesa, the initial install appears as "hung" system since DRI is enabled by default.

Yes, you can always file a bug. Probably no developers will have time to fix it properly, but at least DRI should default to off if it causes hangs.

Oh and by the way, you can check if that AGP mode "0" bug is the same by trying out other AGP speeds (1,2,4). If you hit the right speed, the message should change from 0x to your value.

[str8bs]

Tormod,
Thank you for taking a look. It appears you attempted to solve my problem last year. :)
I was not able to get the "0x" to change using other agpmode=. May be expected, but odd that XorgLog reports "8" as "illegal" but not 4 even though this card is only 2X?

I went ahead and opened bug report. https://bugs.launchpad.net/ubuntu/+bug/1023975

I keep googling myself to confusion regarding GIT. Is there a way I could test your patch? What search terms would lead me to the equivalent of "GIT for Dummies?"

[bipa]

Sorry for waking up this old thread. I hope I'm not violating forum rules here but this thread seemed relevant to the problem I have.

I'm currently trying to revive an old G3 iMac DV+ (450 MHz G3 CPU) with Ubuntu 12.04 (this is actually for the local Kindergarten so children can learn playing with gcompris and stuff like that).

This model has an ATI Rage 128 Pro AGP 2x with 8 MB of VRAM.

Following the "PowerPC FAQ" and "PowerPC known issues" instructions (thanks to the people who took the time to write these), I managed to install everything pretty well, but I still believe the video performance is rather poor so I wanted to try to enable all possible accelerations.

Thank to str8bs's instructions and sample xorg.conf bits (found on several forums), I tried to activate DRI, but it looks like I have a special behaviour :

- I installed kernel-firmware-nonfree
- I downgraded the 4 libgl-mesa* deb packages to version 7
- I have AIGLX and Composite disabled
- I added the "ForcePCIMode" to xorg.conf
- I have the "CCEusecTimeout" parameter set to 100000

When I try at 1024x768 @ 24 bpp, I get an error message saying that I need at least 9 MB of VRAM, so DRI is disabled. Not sure whether AGP mode would lift this memory requirement? The system is fairly useable, noticeably faster than with framebuffer driver, but GLX is completely unavailable.

So I tried at 800x600 @ 24 bpp and 1024x768 @ 16 bpp, but everytime I get a corrupt screen and no explicit error (according to the logs, everything is fine and DRI is enabled). Also the dmesg looks ok (with drm startup messages), although I do see the aforementioned messages about agpgart not finding any VGA adapter. But despite the absence of severe error messages, the screen stays garbled : in single-user mode I can still Ctrl-Alt-Backspace out of it, but in normal mode I have to hard-reset the machine.

At some point (not after all attempts), I noticed the following message in Xorg.0.log:

(EE) R128(0): R128CCEWaitForIdle: (DEBUG) CCE idle took i = 1025

(despite the CCEusecTimeout option being set in xorg.conf)

So maybe this is the same kind of issue str8bs was referring to (the X server not being completely crashed but rather extremely slow, but I didn't have the patience to wait until a non-garbled login screen shows up).

I can add a word about the actual "garbage" I see on screen :

- in 16 bpp mode, it's like the screen is subdivided in two halves vertically : the upper half has some remnants of text from the console and the bottom half is filled with a dithered green/grey-ish color

- in 24 bpp mode 800x600, the top half is black and the bottom half has some orange-ish pixel garbage spread horizontally

Anybody (especially str8bs) can tell me if they already observed a similar behaviour and if there is a known fix? Thanks in advance.

PS: BTW I also compiled Tormod's mesa-legacy package, which compiled and installed fine on my iMac G3, but didn't solve the problem either. I can provide the binary powerpc deb packages in case anybody is interested.

[str8bs]

@ Mods - Sorry for bumping an old one. Been away and just noticed the previous post requesting help.

@BIPA - I never tested on one with less than 16mb VRAM. Maybe you can confirm, but I speculate "forcePCImode" bug/issue may only apply to the Rage 128 Ultra 16M which is AGP 2X with a chipset that allowed greater than 2X speeds.

I can say the "half and half" garbled screen behavior is what I would see in the "extremely slow" failure without "forcePCImode."
I don't think the VGA arbitration (vgagarb) error is relevant to this issue. You should only need "forcePCIMode" if you see the one with "putting AGP ... 0x mode." If you don't see that, or see something other than 2X, I would try forcing 2x in the xorg.conf.

You should not need to disable AIGLX or composite. Firmware non-free did nothing to help mine either.

DRI will automatically be disabled with VRAM less than 9M at higher res and depth. One of the things I was curious about with your hardware is if you get CAN get DRI enabled in AGP mode, you might be able play with GART size to increase shared memory available. (Keep in mind the 100Mhz bus speed on these things. Any trip across that bus will be slow. It is 66Mhz on the 333 cpu and older.)

I would start trying something that won't auto disable DRI like 16 bit 800x600 or 640x480. (You will have to add mode lines to support those.)
If you get that working, experiment with GART size and check your logs to see if it gives you the RAM.(See my July 11 post this thread.) If so, try upping the res and depth again and add "enabled" in the DRI section. (I think will force it on.)