Like @juancarlosonetti said, disabling hardware acceleration provides a slight bump in performance, but Spiderweb ironically still has the edge. Puzzling.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Making G3s and Radeon graphics great again
- Thread starter juancarlosonetti
- Start date
- Sort by reaction score
Okay, this is weird. Adding your kernel option made Xorg stop freezing. So I thought, what if I do this with the up-to-date drivers?
I uninstalled xorg and all its dependencies, I removed the pin of these packages, and installed the Sid version of Xorg. I rebooted, and, at the yaboot command line, booted the kernel like this:
Code:
Linux video=radeonfb: off radeon.modeset=1 radeon.agpmode=-1And... It works. It still has terrible performance, so there's (probably) no 3D acceleration yet. But I'm clueless as to what can be causing this.
I then rebooted again, and booted the 4.19 kernel provided by the Sid repositories. The flickering started again. This makes me realize that this was not a Xorg problem. It was not a driver problem. It was a kernel problem! Or, at least, a problem of the mix of this particular version of the kernel with this particular version of the drivers.
This renders the entire guide useless. The question now is: What the hell is going on?
Not necessarily. Before you made this guide, we didn't even have functioning 2D acceleration. This is a big step in the right direction.
Possibility 1. Of course it's a kernel problem. You see, shortly before the release of Debian Jessie, Tux had a little too much beer when partying with his friends and gained a disability that effectively renders him permanently intoxicated. Now he has to live life as a handicapped penguin that requires special drivers, techniques, magic words, and technical wizardry every day.
The Intel machines are of course powerful enough to care for handicapped Tux's many demands, and usually get by perfectly fine.
PowerPC G3s however, just can't withstand the weight of responsibility handicapped Tux requires and will crumble when tasked with such requests, exhibiting flickering screens, sputtering sound, and stubborn boot processes.
Poor G3s...
- - - - -
Possibility 2. Maybe it's a combination of problems.
My working take is that it has to do with kernel 3.16+, systemd over init, and KMS.
Of course, Jessie added all this, so that's where we first saw problems.
If we can get the custom 4.4 in, replace systemd with init, and perhaps do something with the nonfree Radeon firmware, then I believe we might truly be getting places.
Last edited:
Lets just take him out to pasture, ok? It would be inhumane to allow the poor guy to suffer
.Every time I dick around with PowerPC Linux, I wind up walking away from it sulking, because insurmountable problem, after insurmountable problem arises, and I realize how much simpler it is to fiddle around with a Pentium 4 autism box, kek.
Here's my take. For most G3s (iBooks especially), keep them on OS X. They simply don't like Linux, but will fare great with an optimized Tiger / Camino.
G4s are a mixed bag. Some of them should stay on OS X, but others will play nicely with Linux.
Most all G5s are just fine on Linux and should encounter few problems along the way.
It's all up to discretion. My philosophy is not to try fixing something that has already made clear it doesn't want to work. However, if a machine largely embraces Linux (or anything else) from the beginning with just a couple of issues, then you fix those and be on your merry way.
We have enough options on all sides where we can afford to make these choices, which again, goes back to discretion.
Doesn’t Camino lack many modern security cyphers? Last time I tried to use it, I had a hard time connecting to quite a few sites.
Yes. But it's fast, and will connect fine to Macintosh Garden, MacRumors, Wikipedia, and other lighterweight sites. Basic research usages will also do fine.
When you're on a G3, you can't just stop with a light OS. You need a light browser. You even need light websites.
For a 1999 computer running a 2005 OS, why is a 2012 browser so shocking?
It's not shocking, just disappointing. I can browse the internet on Windows XP (OS from 2001) with a Pentium 3, and use a secure browser, with up to date security patches (Roytam1's weekly 32-bit no SSE PM27 build). And, it's fast, to boot. You would agree that it's sad the best we can do for G3's is a browser from 2012, correct? FYI, Spiderweb is actually quite usable on JS heavy websites with a G3. The only thing holding G3's back from usability in 2019 is the stupid ****ing Radeon problem.
Last edited:
I really like this sentence.
Replace 'G3' and 'Radeon' with any other couple issues, and you have a fine summarization of the frustration of modern day retro computing.
There's always that single thorn in the side to any one configuration. The Achilles hell (not heel) ...
@juancarlosonetti As far as I know the radeon userspace DRI driver stopped being offered in kernel config from 3.4.x onwards, which presumably makes sense since 3.4.x first shipped with jessie, while wheezy repos (not -backports) offered up to 3.2.x which had userspace radeon. Though I may not be 100% correct (maybe even just wrong).
Mind uploading your xorg.conf? I'm not sure I can do anything but I'm somewhat curious.
Mind uploading your xorg.conf? I'm not sure I can do anything but I'm somewhat curious.
Though that doesn't change what I said, you're correct.
Another update:
Debian Sid has upgraded the kernel, from 4.19 to 5.2. Radeon graphics are still freezing, BUT if I compile the same kernel version with the same configuration as the 4.4 kernel I uploaded, 2D graphics start working again.
As far as I know, the only relevant setting that is different on my kernel is that I have compiled the Radeon framebuffer inside the kernel, and not as a module, like the default kernel does. My system is up and running with 5.2.7.
So maybe it's this easy?
Debian Sid has upgraded the kernel, from 4.19 to 5.2. Radeon graphics are still freezing, BUT if I compile the same kernel version with the same configuration as the 4.4 kernel I uploaded, 2D graphics start working again.
As far as I know, the only relevant setting that is different on my kernel is that I have compiled the Radeon framebuffer inside the kernel, and not as a module, like the default kernel does. My system is up and running with 5.2.7.
So maybe it's this easy?
So can you please update your guide to the latest kernel to the brave ones who will do this upgrade sooner or latter? Thanks
Okay, so this was a false alarm. It seemed to work, but it really didn't. I will explain why.
When you compile the radeon framebuffer inside the kernel, instead of as a module, it breaks KMS. And, when booting with that kernel, Xorg will load the amdgpu driver, as opposed to the radeon driver. It works, but it is no different than just specifying the amdgpu driver in your xorg.conf with the default kernel, and it also delivers worse performance.
When trying to load the radeon driver, you are greeted by an error:
Code:
[KMS] drm report modesetting isn't supportedSo no, this is not a real solution. We will need to keep thinking about this.
[doublepost=1565399707][/doublepost]
As you can see, the new kernel wasn't really working, so if you currently have no graphics I recommend following the guide and, if you have working graphics, I recommend sticking with your system as-is. The graphics after following the guide will be slow.
So far I haven't succeeded in getting the radeon driver working with any pre-r300 chipset on a powermac. A radeon 9600 in pci mode (radeon.modeset=-1) works just fine with the nonfree firmware blobs while a radeon 9000 with the same good config and the appropriate blob will just hang the X server and the screen will flicker until I manage to kill X or simply reboot. I can set Option "NoAccel" "true" under the driver section of my X.org config, but then we're back to slow raster graphics.
Depending on how motivated you are about getting radeon 100% working on your iBook, I think you should consider configuring your kernel with fbdev built-in and completely disable DRI (or, just use the stock kernel with nomodeset in yaboot and load the radeonfb module). built-in radeonfb might just improve performance slightly vs. a kernel module. fbdev is robust, more compact and has less abstraction than DRI/KMS. It'll perform better than DRI if you can't get hardware accel working at all. No need to mention sleep works.
Sorry for a dumb question but how did you install the blobs for radeon 9600? I am running a Radeon 9650 in my PMG5 and have installed the firmware-amd-graphics from the Powerprogress (https://repo.powerprogress.org/debian/dists/sid/main/binary-ppc64/Packages) repo. The issue I am having is screen turning blank when the system switches to KMS during boot. Nomodeset and fbdev work but I would really like the radeon card working fully.
Distros use these firmware blobs by loading them off an initramfs during boot process. When you install such a package via your package manager, (debian?) should install the firmware at the right place and then regenerate the initramfs. There's nothing else to do. Doesn't look like the issue here is missing firmware.
Not sure what to say. By "when the system switches to KMS" you really mean during early boot when the video mode is set?
Sorry, should have mentioned I am using Debian Sid.
I can get to around halfway the boot process and can see the initial systemd log with a bunch of [OK]'s. Where the monitor blanks out is where normally the console font would change. So I'm guessing this is where the video mode gets set.
I know that the system boots because I can blind-type the commands and they work (e.g. /sbin/reboot). Also as I said nomodeset gets me through the boot process just fine but I am limited to using the fbdev Xorg driver at the end as the radeon one complains about KMS being unavailable.
Today I spent the day rolling back to Debian Wheezy, and followed these instructions:
So it seems like you are right, @XaPHER, and the userspace DRI on Linux 3.2.x works just fine.
At this point, having spent so many weeks on this, I am seriously thinking about making a fork of the 3.2.x kernel, trying to backport all recent security patches to it, disable all insecure components, and hack together all my preferred things into a new distro, just because why not. It would certainly take a long time, but it would be fun and I would learn a lot in the process. It would not be anything professional, since I'm not even a developer myself, but at least it would work, and it would be reasonably up-to-date.
Old notes
Finally, I'll leave some old notes that only apply to Wheezy and Ubuntu's still supported 12.04 LTS:
[...]
If KMS just doesn't work for you [...], you can try a second method. First, downgrade these four Mesa packages (they're labeled ubuntu but they work the same on Debian):
libgl1-mesa-dri_7.11-0ubuntu3.3_powerpc.deb
libgl1-mesa-glx_7.11-0ubuntu3.3_powerpc.deb
libglapi-mesa_7.11-0ubuntu3.3_powerpc.deb
libglu1-mesa_7.11-0ubuntu3.3_powerpc.deb
Download the .deb files, use the cd command to change your current directory to the directory of the .deb files, and then run the following:
This assumes there are no other .deb files in that directory (the "*.deb" means the command will apply to all .deb files in that folder). Then reboot, and at the second Yaboot screen enter the following to ensure KMS is disabled:
[...]
Now lock the mesa packages to prevent them from updating.
And, amazingly enough, this WORKED. I have 3D acceleration, and the machine is a pleasure to use again. Running "glxgears" returns a very decent performance:Finally, I'll leave some old notes that only apply to Wheezy and Ubuntu's still supported 12.04 LTS:
[...]
If KMS just doesn't work for you [...], you can try a second method. First, downgrade these four Mesa packages (they're labeled ubuntu but they work the same on Debian):
libgl1-mesa-dri_7.11-0ubuntu3.3_powerpc.deb
libgl1-mesa-glx_7.11-0ubuntu3.3_powerpc.deb
libglapi-mesa_7.11-0ubuntu3.3_powerpc.deb
libglu1-mesa_7.11-0ubuntu3.3_powerpc.deb
Download the .deb files, use the cd command to change your current directory to the directory of the .deb files, and then run the following:
Code:
sudo dpkg -i *.debThis assumes there are no other .deb files in that directory (the "*.deb" means the command will apply to all .deb files in that folder). Then reboot, and at the second Yaboot screen enter the following to ensure KMS is disabled:
Code:
Linux radeon.modeset=0[...]
Now lock the mesa packages to prevent them from updating.
Code:
$ glxgears
3386 frames in 5.0 seconds = 677.081 FPS
2928 frames in 5.0 seconds = 585.465 FPS
3362 frames in 5.0 seconds = 672.328 FPSSo it seems like you are right, @XaPHER, and the userspace DRI on Linux 3.2.x works just fine.
At this point, having spent so many weeks on this, I am seriously thinking about making a fork of the 3.2.x kernel, trying to backport all recent security patches to it, disable all insecure components, and hack together all my preferred things into a new distro, just because why not. It would certainly take a long time, but it would be fun and I would learn a lot in the process. It would not be anything professional, since I'm not even a developer myself, but at least it would work, and it would be reasonably up-to-date.
Last edited:
I certainly admire your determination! Great work! I for one, would definitely use your distro.
Added a section dedicated to different Xorg optimizations. @sparty411, you might find this useful.
Cool, I'm going to do a fresh install this weekend when I have some time.