Snow Leopard on Unsupported PowerPC Macs

[B S Magnet]

@barracuda156: 10.6 says there’s no hardware support for QE or CI. The GPU definitely supports these though.

Thanks for the link. I must have forgotten to put that in the WikiPost.

This appears to be one of the Radeon GPUs which supports OpenCL and uses post-BrookGPU firmware — which could help to explain why it has hardware support for CI/QE in Snow Leopard retail and later.

 

[tensixturtle]

Hi,
I have tried a few more things to try to get BT to work but I am completely out of ideas at this point. Are there some last things I should try with this? I have attached my log of different combinations.
Thanks

 

[barracuda156]

Hi,
I have tried a few more things to try to get BT to work but I am completely out of ideas at this point. Are there some last things I should try with this? I have attached my log of different combinations.
Thanks

I can check next month.

 

[barracuda156]

[This is Macports-related, but also specific to 10.6 PPC:]

If anyone gets ports build failures on 10A190, please port here reports (port name, error, preferably log): https://forums.macrumors.com/thread...-6-powerpc-10a190-and-10-6-8-rosetta.2332711/

Tickets against 10.6 PPC will not be accepted on https://trac.macports.org (though tickets against 10.6 Rosetta will be). And while I won’t be able to “sell” 10A190-specific fixes to Macports, in majority of cases failures are either common for all PPC systems or shared with 10.6.8 Rosetta, and then I can bring a fix into Macports. In fact, larger part of my fixes for Rosetta is already there, but I wanna know which other ports fail. Hence asking here.

Unless I find some clever way to make an acceptable fix for gcc10+, portfiles for gcc10-bootstrap, gcc10, gcc11 and gcc12 will have to be taken from elsewhere (I will make a branch on my Github), because those are 10A190-specific, Rosetta builds work fine (aside from gcc10-bootstrap atm). But other than that, I hope using Macports on 10.6 PPC will soon be as easy, as on Leopard.

 

[game.power]

Hi all!

Maybe a bit lame question, but is there a chance to build a bootable ISO? At least for Power Mac G5 series. I'm running PowerMac G5 (DP@2.3GHz, 7,3) and not quite sure I'll be able to prepare everything on this single machine and eventually boot it. @Larsvonhier any ideas?

 

[Amethyst1]

Hi all!

Maybe a bit lame question, but is there a chance to build a bootable ISO? At least for Power Mac G5 series. I'm running PowerMac G5 (DP@2.3GHz, 7,3) and not quite sure I'll be able to prepare everything on this single machine and eventually boot it. @Larsvonhier any ideas?

There'a a disk image of a pre-installed 10A190 floating around: #200

 

[game.power]

Will give it a try. Thanks!

 

[barracuda156]

There'a a disk image of a pre-installed 10A190 floating around: #200

Plus an similar image for 10A96 (though 10A190 is generally preferable IMO).

 

[barracuda156]

Which executable?

Just in case, has there been any progress with rebuilding system components?

 

[ChrisCharman]

Just in case, has there been any progress with rebuilding system components?

Hello mate

I have a lot going on in my personal life at the moment so have had to take a break from the project. Will update the thread when i’m able to contribute again.

 

[barracuda156]

How to get the latest GCC (12.2.0) going on 10A190

Use portfiles from here: https://github.com/barracuda156/macports-ports/tree/snow-ppc

You can see changes in commit history.

gcc10-bootstrap: https://github.com/macports/macports-ports/commit/b1f494682901b72388e1673b6ff04dac4b94f319 (needed to build gcc11/gcc12).
gcc12: https://github.com/macports/macports-ports/commit/e142f152d0ee60c99a36615ab3f8a6a25280913d (if you are on G4, change G5 to G4 in --with-tune-cpu=.

So what will be needed (after portfiles and patches are updated from my tree):
sudo port -v install gcc10-bootstrap
sudo port -v install libgcc12 gcc12

 

[barracuda156]

Well, for now we can stick with the PowerPC OpenCL runtime if i manage to find it again.

Have you found it? POCL turned out to require LLVM, so not an option (portable, how ironic).

 

[pc297]

Thanks for the link. I must have forgotten to put that in the WikiPost.

This appears to be one of the Radeon GPUs which supports OpenCL and uses post-BrookGPU firmware — which could help to explain why it has hardware support for CI/QE in Snow Leopard retail and later.

Isn't the X1900 still BrookGPU? AFAIK it doesn't support OpenCL, nothing under Radeon HD 4XXX does, all GPU-based computations up to including HD 3XXX cards are BrookGPU-based for the ones that support it

Ironically OpenCL works perfectly with RadeonHD cards >= HD 4000 under ppc linux!

 

[pc297]

Have you found it? POCL turned out to require LLVM, so not an option (portable, how ironic).

What's wrong with the llvm provided by Xcode? Seems to work fine under 10A190

 

[B S Magnet]

Isn't the X1900 still BrookGPU?

It is. The X1900 XT premiered in time for the MacPro1,1 in August 2006; OpenCL’s formalized origins didn’t come to the fore prior to June 2008, though it’s clear Apple were working on it internally (probably alongside GPU vendors like NVIDIA, under tight wraps) for at least a year or more before that.

AFAIK it doesn't support OpenCL, nothing under Radeon HD 4XXX does, all GPU-based computations up to including HD 3XXX cards are BrookGPU-based for the ones that support it

I believe you’re correct, though it’s worth noting how there are some OpenCL-compliant GPUs on the list which were developed in 2007 (notably, the GeForce 8600M GT bundled first with the Santa Rosa-era MBPs (MBP3,1) — lending as evidence that close partnership on OpenGL’s road map between Apple and NVIDIA was happening well before the formalizing before the Khronos Group.

Ironically OpenCL works perfectly with RadeonHD cards >= HD 4000 under ppc linux!

You may want to double-check whether PPC Linux is actually involving OpenCL computing on the cards you’ve tested — namely, verifying whether PPC Linux is using the GPU RAM for CPU-related tasks (and unrelated to VRAM).

Per the above-linked source, at least three cards from that Radeon HD 4xxx-series are not use OpenCL (the 4670, 4850, and 4870), though all will, on the OS X side, run Snow Leopard without a hitch. My guess is there’s a special fallback to BrookGPU instructions, but I’m only speculating.


On an unrelated note: this reply got me to find a preview blog mention of Build 10A286’s changes from its predecessor released to developers from a user-testing vantage (rather than the formal developer notes), replete with screen caps of their findings (which is a nice thing to see!). It’s entirely possible I’ve seen it before but have no memory of it, but it’s a nice to have nevertheless.

 

[B S Magnet]

How to get the latest GCC (12.2.0) going on 10A190

Use portfiles from here: https://github.com/barracuda156/macports-ports/tree/snow-ppc

You can see changes in commit history.

gcc10-bootstrap: https://github.com/macports/macports-ports/commit/b1f494682901b72388e1673b6ff04dac4b94f319 (needed to build gcc11/gcc12).
gcc12: https://github.com/macports/macports-ports/commit/e142f152d0ee60c99a36615ab3f8a6a25280913d (if you are on G4, change G5 to G4 in --with-tune-cpu=.

So what will be needed (after portfiles and patches are updated from my tree):
sudo port -v install gcc10-bootstrap
sudo port -v install libgcc12 gcc12

This is probably something obvious to a developer or software engineer (though not to me… plus, my mind is rusty after pausing my own work on this project over the summertime):

Do you expect that kernel changes between 10.0.0d1 and 10.0.0d2 generally prohibits the functionality/usability of command-line-level binaries (of BSD/system software, i.e., /bin, /sbin, etc.) found in 10A190 to prevent functionality in a 10A96 setting?

(This isn’t related to the matter of 10A190-related tweaks to, say, macports not working in 10A96, but the question is kind of adjacent to that.)

 

[pc297]

It is. The X1900 XT premiered in time for the MacPro1,1 in August 2006; OpenCL’s formalized origins didn’t come to the fore prior to June 2008, though it’s clear Apple were working on it internally (probably alongside GPU vendors like NVIDIA, under tight wraps) for at least a year or more before that.




I believe you’re correct, though it’s worth noting how there are some OpenCL-compliant GPUs on the list which were developed in 2007 (notably, the GeForce 8600M GT bundled first with the Santa Rosa-era MBPs (MBP3,1) — lending as evidence that close partnership on OpenGL’s road map between Apple and NVIDIA was happening well before the formalizing before the Khronos Group.




You may want to double-check whether PPC Linux is actually involving OpenCL computing on the cards you’ve tested — namely, verifying whether PPC Linux is using the GPU RAM for CPU-related tasks (and unrelated to VRAM).

Per the above-linked source, at least three cards from that Radeon HD 4xxx-series are not use OpenCL (the 4670, 4850, and 4870), though all will, on the OS X side, run Snow Leopard without a hitch. My guess is there’s a special fallback to BrookGPU instructions, but I’m only speculating.


On an unrelated note: this reply got me to find a preview blog mention of Build 10A286’s changes from its predecessor released to developers from a user-testing vantage (rather than the formal developer notes), replete with screen caps of their findings (which is a nice thing to see!). It’s entirely possible I’ve seen it before but have no memory of it, but it’s a nice to have nevertheless.

I'll post some screenshots of the BOINC event log on debian sid (bookworm) ppc when I get a chance, but both the HD 4870 and 5770 definitely get initialised as OpenCL compute units (with peak FLOPS quoted) with GPU VRAM available for computation.

Here is a link to my Quad G5 showing up on milkyway@home in the meantime with OpenCL 1.1 (Radeon HD 5770):

Computer 908122

Not that I've actually run anything on it so to say, save the GPU computation benchmarks, let alone real science computations, the client for it simply doesn't exist for obvious reasons (although I've been tempted to compile it, but then again I would likely have to find a big-endian modified source)

Re HD 4XXX cards, I did run seti@home using OpenCL on HD 4650 and HD 4670 cards using OpenCL 1.0 on Windows:

Computer 6684594

setiathome.berkeley.edu

~85 GFLOPS for Astropulse, I was pretty happy with it, comparable to the GeForce GTX 9800 X2 off the top of my head (when I had one) and much faster than BrookGPU which I had tried on the HD 3870 but was barely above 10 GFLOPS... Of course cards like the GF 460 will run at ~650 GFLOPs on the same task



Re 10A286 very interesting article as this shows that 10A286 is the earliest version of SL "as we know it" as it seems to implement most of the notable visual differences between Leopard and SL. If somehow critical ppc components e.g. the Finder etc could be obtained, this would definitely be the build to be after

 

[barracuda156]

This is probably something obvious to a developer or software engineer (though not to me… plus, my mind is rusty after pausing my own work on this project over the summertime):

Do you expect that kernel changes between 10.0.0d1 and 10.0.0d2 generally prohibits the functionality/usability of command-line-level binaries (of BSD/system software, i.e., /bin, /sbin, etc.) found in 10A190 to prevent functionality in a 10A96 setting?

(This isn’t related to the matter of 10A190-related tweaks to, say, macports not working in 10A96, but the question is kind of adjacent to that.)

Honestly no idea, I just do not work on 10A96, so nothing gets tested on it, and I wanna avoid creating false expectations. (Since 10A190 is fully functional with regard to command line tools, I see no point being stuck on an earlier DP. If anything, move from 10A190 should be upward towards 10.6.8, however close is feasible.)

But nothing stops you from trying to build gcc10 on 10A96 – just do not use Macports for that. Patches should be the same anyway.

Clone gcc10 from Iain tree: https://github.com/iains/gcc-10-branch/tree/gcc-10-3-ppc
Use my patch for gcc/config/darwin.h
To make life easier, here is the patched branch: https://github.com/barracuda156/gcc-10-branch/tree/gcc-10-3-slppc

Create a build dir outside the source, change to it. Configure gcc10 it with:

/PATH_TO_GCC10_SOURCE_FOLDER/configure --prefix=/WHERE_YOU_WANNA_INSTALL --build=powerpc-apple-darwin10 --with-as=/usr/bin/as --with-ld=/usr/bin/ld --enable-languages=all -with-tune-cpu=G4 CC=/usr/bin/gcc-4.2 CXX=/usr/bin/g++-4.2 --with-sysroot=/ --enable-host-shared --disable-nls >conf.txt

Then (assuming you use a PowerBook, so 1 CPU):

time nice make -j1 STAGE1_CFLAGS="-O1 -pipe -mdynamic-no-pic" STAGE1_CXXFLAGS="-O1 -pipe -mdynamic-no-pic" >b.txt 2>e.txt

Then sudo make install.

P. S. It may fail though, and fixing Macports for 10A96 is likely gonna be easier than fixing GCC standalone build. But who knows, maybe on 10A96 it gonna work.

 

[barracuda156]

What's wrong with the llvm provided by Xcode? Seems to work fine under 10A190

You mean llvm-gcc-4.2? It is largely broken for ppc, but works for something, sometimes. But it is not llvm proper.
Then, older versions of llvm build – but do not work. Some details: https://github.com/iains/darwin-toolchains-start-here/discussions/29#discussioncomment-3544024

 

[B S Magnet]

I'll post some screenshots of the BOINC event log on debian sid (bookworm) ppc when I get a chance, but both the HD 4870 and 5770 definitely get initialised as OpenCL compute units (with peak FLOPS quoted) with GPU VRAM available for computation.

Here is a link to my Quad G5 showing up on milkyway@home in the meantime with OpenCL 1.1 (Radeon HD 5770):

Computer 908122

First thing, this is interesting to learn. It leaves me to wonder whether ATI/AMD wrote firmware updates for native parsing of OpenCL/compute shader commands, or whether they wrote later drivers for linux to work with OpenCL. I honestly don’t know. Second, the link to that data was down, but I’ll try to check it again later. Third, off-topic: I used to eye Rensselaer to continue an area of research I was working on in grad school.

Not that I've actually run anything on it so to say, save the GPU computation benchmarks, let alone real science computations, the client for it simply doesn't exist for obvious reasons (although I've been tempted to compile it, but then again I would likely have to find a big-endian modified source)

Re HD 4XXX cards, I did run seti@home using OpenCL on HD 4650 and HD 4670 cards using OpenCL 1.0 on Windows:

Computer 6684594

setiathome.berkeley.edu

~85 GFLOPS for Astropulse, I was pretty happy with it, comparable to the GeForce GTX 9800 X2 off the top of my head (when I had one) and much faster than BrookGPU which I had tried on the HD 3870 but was barely above 10 GFLOPS... Of course cards like the GF 460 will run at ~650 GFLOPs on the same task

That’s awesome. Interestingly, I tried running the final BOINC UB client in Leopard on my G5 a couple of years ago. Despite leaving it running and having selected any of five active @home projects for BOINC to manage, I was unable to get any of those projects to send chunks to process. I sussed it to the G5 being far too slow for what those projects needed. In the end, I’ve only managed to get BOINC projects to run on my later Intel Macs.

Re 10A286 very interesting article as this shows that 10A286 is the earliest version of SL "as we know it" as it seems to implement most of the notable visual differences between Leopard and SL. If somehow critical ppc components e.g. the Finder etc could be obtained, this would definitely be the build to be after

Build 10A286 is notable for a couple of reasons: it was the first developer build to run a completely Cocoa-based Finder, and it was the final build to explore zfs support before Apple yanked it.

Visually speaking, however, I can attest from applied use that even Build 10A96 is different visually from Leopard: default gamma settings are a slight bit higher (more contrasty); and system type display (dfonts) is slightly tighter, much as default grid spacing in Finder also is. Many of these elements have remained consistent across all the Developer builds and into the retail editions. If you want, I have some screencaps buried somewhere displaying some of these visible differences.

It helps that my test mule, a PowerBook, has both Build 10A96 and 10.5.8 on different partitions, and running both makes it possible to run screen cap side-by-sides, and it’s also possible to bring over 10A96 dfont elements to Leopard to implement those tighter-kerned fonts.

That said, yes, QuickTime X elements became visible from Build 10A286, and some of the Cocoa-only elements for Finder are not present in the Carbonized Finder on Builds 10A96 through 10A261.

 

[pc297]

First thing, this is interesting to learn. It leaves me to wonder whether ATI/AMD wrote firmware updates for native parsing of OpenCL/compute shader commands, or whether they wrote later drivers for linux to work with OpenCL.

Under ppc linux, firmwares are read from firmware-linux-nonfree, which is a universal package - so not a big endian firmware package - but ppc linux uses it, I think because the driver was simply ported from x86 and expects the ROM at a certain x86-specific address, which doesn't exist under ppc. From what I understand parts of the little-endian firmware are then byte-swapped for BE under ppc linux. Works like a charm in any case under ppc linux, and the desktop is hardware-accelerated and OpenCL supported. I am trying to do something similar using the (x86) OSX port of the driver, the first step is to load the firmware from file, this is where I am right now. Re HD 4XXX cards, all RV7XXX cards have hardware support for OpenCL afaik:

Radeon HD 4000 series - Wikipedia

en.wikipedia.org

But going back to OpenCL, you don't have to have an OpenCL-compliant card to run SL, the mini for example never had that (GMA-850) but it still supported QE/CI etc under SL

Second, the link to that data was down, but I’ll try to check it again later.

Must be maintenance day on milkyway@home! (SETI@home used to be Tuesdays)

That’s awesome. Interestingly, I tried running the final BOINC UB client in Leopard on my G5 a couple of years ago. Despite leaving it running and having selected any of five active @home projects for BOINC to manage, I was unable to get any of those projects to send chunks to process. I sussed it to the G5 being far too slow for what those projects needed. In the end, I’ve only managed to get BOINC projects to run on my later Intel Macs.

This was using OpenCL under Radeon HD 46XX cards under Windows. But even if I had tried it under ppc linux a couple of years back when SETI@home was still running, there wouldn't have been a ppc OpenCL client, sadly. But who knows, now that ppc64le is progressively replacing ppc/ppc64 and makes porting a lot easier due to the endianness being the same as x86 and mainstream ARM, we might have an OpenCL ppc64le client for POWER8-10 systems. I got ahold of a POWER7+ system that I'm currently rebuilding, and Debian 8 originally was boostrapped for that too (although not anymore), I might be able to tell you either by running it natively or in possibly via qemu-kvm even though this would require a GPU passthrough which does exist for the x86 version of qemu, but I am not sure this was ported to the ppc version.

Re the G5 running BOINC I did run CPU tasks on it but it wasn't so good, which is a shame because theoretically RISC has inherent advantages over CISC especially for FP ops, taking fewer cycles; I guess the client was never optimised for RISC... In any case I think there was no official AltiVec client and it was the same one running on G3s-G5s. That said there were some unofficial AltiVec clients:

Optimized Client Versions or Source code?

In any case I stopped using it after it did contribute to frying my previous Quad:

Computer 6825520

setiathome.berkeley.edu

Visually speaking, however, I can attest from applied use that even Build 10A96 is different visually from Leopard: default gamma settings are a slight bit higher (more contrasty); and system type display (dfonts) is slightly tighter, much as default grid spacing in Finder also is.

Sure, but it looks like they introduced e.g. the grid version of Applications with subfolders (which will simply open in Finder under Leopard) also viewed as grid in 10A286, among other things?

 

[B S Magnet]

But going back to OpenCL, you don't have to have an OpenCL-compliant card to run SL, the mini for example never had that (GMA-850) but it still supported QE/CI etc under SL

I know. That’s what I mentioned earlier, though I think I could have worded it better.

Must be maintenance day on milkyway@home! (SETI@home used to be Tuesdays)

No worries! I’ll check again later.

Sure, but it looks like they introduced e.g. the grid version of Applications with subfolders (which will simply open in Finder under Leopard) also viewed as grid in 10A286, among other things?

I’m not quite sure what you’re referring to here?

 

[pc297]

I’m not quite sure what you’re referring to here?

The stacks feature in grid view supporting subfolders, my bad

Stacks (Mac OS) - Wikipedia

en.wikipedia.org

It looks like the 10A286 version is as funcitonal as in 10A432?

 

[B S Magnet]

The stacks feature in grid view supporting subfolders, my bad

Stacks (Mac OS) - Wikipedia

en.wikipedia.org

It looks like the 10A286 version is as funcitonal as in 10A432?

Ah ok. I see how you mean here.

Yeah. As, this isn’t a feature I use, I went ahead and tried it out with 10A96 and then compared it with 10.6.8.

For one, the options menu (right-clicking on the stack) in 10.6.8 is the dark, translucent style found with later Snow Leopard UI features, while the 10A96 version’s options menu is the more conventional light grey, opaque background (and lacking the ability to view sub-folders within Stacks). Both versions show basically the same Stacks options.

Both Stacks backgrounds use that dark, translucent grey we tend to associate with the more recent Snow Leopard builds, so at least that much made it into 10A96.

My guess is, as part of the full Cocoa re-write, the Stacks portion (I’ll have to check if there’s a Stacks framework somewhere) was re-written in parallel, along with Dock.

I haven’t tested running 10A286 or later on any system. I might do so if I end up with a new mule for use with stuff like this, but it’s not in the cards right now.

 

[MacPro2006VBox]

Thought I’d share a handy utility that could potentially enable QE on our AGP systems… iMNC alluded to it to allow PCI GPUs such as the Mac version of the Radeon 9200 to use Quartz Extreme on G3 PowerMacs.

https://macintoshgarden.org/apps/pci-extreme