Figuring out Mac OS X 10.4-10.6

Creating ultra fast virtual machines of old operating systems for fun and profit
Post Reply
User avatar
MattKC
Site Admin
Posts: 323
Joined: Mon Aug 22, 2022 1:05 am
Contact:

Figuring out Mac OS X 10.4-10.6

Post by MattKC »

This is mostly an infodump/ramble thread. There won't be a lot of background/explanation/tutorial, I'll generally assume if you're here, you have at least some familiarity with what I'm talking about.

So I'm trying to get OS X 10.4-10.6 working on QEMU/KVM with full GPU passthrough. I've now got each of these booting inside QEMU/KVM utilizing OpenCore, now it's just a matter of getting the GPUs working.

Right now I'm primarily using an ATI Radeon HD 2400 XT, which has been flashed to be a 2400 Pro for greater compatibility with Mac OS. I was originally using an ATI Radeon HD 3870, which I'd managed to get partially working before swapping it out, but was interested in how common the 2400 XT/Pro was (right now several are available on eBay for only $5) and how accessible that would make this process for people (also it's single-slot which makes it easier to fit in a lot of cases), so that's become my focus for the time being.

Info

Technically none of this research is "new" - people did manage to get stuff like this working back in 2007-2008 when it was more timely to do so - however much of that information seems to have been lost to the sands of time. While InsanelyMac, one of the biggest Hackintosh forums of that era, is thankfully still up and contains a lot of useful information, many of the links on it are to long-gone websites like RapidShare, Megaupload, or dead personal websites. Additionally, open source was not as common as it is today, so many community-made kexts have no documentation on exactly what they do or how they work. As such, a lot of this information has had to be pieced together from many different sources.

Even though the ATI Radeon 2400 XT shipped with a real iMac that supported 10.4 onwards (iMac7,1 which I'm actually using as my board ID for Hackintosh), that GPU was configured differently from its PC counterpart, so it can't just work out of the box. Even (perhaps especially) on a Mac Pro, the PC version of this card won't work out of the box.

It appears graphics support can generally be split into two categories: the "framebuffer", which enables full resolution and multi-monitor support/switching; and QE/CI (Quartz Extreme/Core Image) which enables hardware 3D acceleration. The framebuffer is crucial, since it enables the most basic graphics functionality (and 3D acceleration cannot operate without it), however for full support we need both.

Unfortunately, the framebuffer is also the most challenging. While you might think 3D acceleration would be the hardest to get working, for the most part enabling it has come down to adding my card's device ID to the 3D acceleration kext. The framebuffer seems to be much more complex.

Mac OS X 10.4 and 10.5

In early versions of Mac OS X (namely 10.4 and 10.5), the ATI framebuffer appears to be enabled through kexts called ATINDRV and ATIRNDRV (for earlier and later models respectively). ATI cards also appear to have "shark names" that correspond to different models, each of which has a plugin in the aforementioned kexts:
Screenshot_20230314_122448.png
Injector kexts exist in order to connect GPUs to these plugins, such as Natit and ATIinject. I've tested these, and while in some cases I may have to correct which framebuffer plugin to inject (my card only works with Megalodon, while some sources/injectors claim the 2400 should be Iago), they do indeed seem to work.

...For the most part. For some reason, I get very noticeable flickering (possible seizure warning):
The flickering is definitely a framebuffer issue. In fact, it's not dissimilar to the flickering I experienced on my Surface Laptop 3 Hackintosh, which may be a clue to fix this, but I can't port the exact fix because that was exclusive to both Intel GPUs and WhateverGreen, neither of which I'm using here.

The 3D acceleration kexts are ATIRadeonX1000 and ATIRadeonX2000, and I got 3D working on this card simply by adding my GPU's device/vendor ID after flashing (0x94c31002) to ATIRadeonX2000's Info.plist. As long as the framebuffer is correct, this seems to work - the ripple effect in the above video indicates correct 3D. The flickering is no different with or without 3D enabled, so it's very clearly a framebuffer issue. However, if there's no framebuffer (or perhaps a too-broken framebuffer), enabling 3D results in nothing but a garbled display.

Currently this is the situation for 10.4 and 10.5. Full resolution switching (using Natit) and 3D acceleration (using a manually patched Info.plist in ATIRadeonX2000), but bizarre flickering in the framebuffer that I haven't yet figured out. Presumably Natit is doing something not quite right, but like I said, Natit is closed source, so it's hard to know what it's even doing in the first place actually there does appear to be some Natit source out there. Might investigate this further.

There are a handful of parameters in Natit's Info.plist, but they're all either numbers or Base64 sequences that don't mean anything to me just yet.

(Note: Interestingly I managed to get full GPU support using a Leopard distro on my HD 3870, but never got it working on a vanilla setup before swapping out the GPUs. Perhaps my current setup my work with the HD 3870, but I haven't tried it yet. The Leopard distro did not work out of the box with the HD 2400, possibly because it too was trying to inject Iago rather than Megalodon.)

Mac OS X 10.6 and above

In 10.6 and onwards, the ATI framebuffer code appears to have been rewritten. As such, Natit and ATIinject no longer work out of the box (in fact they appear to cause kernel panics), and the kexts in question have changed. There's no ATINDRV or ATIRNDRV, instead there's ATIFramebuffer, ATISupport, and various ATIxx00Controllers:
Screenshot_20230314_124834.png
The "shark names" including Megalodon appear to be rolled into ATIFramebuffer, and I have every reason to believe if it was injected correctly, it would work, but clearly it's too different for the 10.4/10.5 injectors.

Today, the main solution for framebuffer patching is with a kext known as WhateverGreen. Unfortunately unlike other modern components like OpenCore/VirtualSMC/Lilu, WhateverGreen only supports as early as 10.6, and my guess is this is because of the apparent framebuffer rewrite that seems to have happened in Mac OS.

Unfortunately, while I've had great luck with more modern AMD and Intel cards, the HD 2400 is not fixed out of the box by WhateverGreen. It appears some degree of manual overriding is going to be necessary, which isn't extremely well documented. WhateverGreen is at least open source and contains "sample SSDTs", but like the numbers and Base64 in Natit, all of this framebuffer stuff is well outside my knowledge right now until I can spend some more time to figure it out.

I've also installed 10.7 and 10.8 with this OpenCore configuration, and they seem to work/not work the same way.

The 3D acceleration kexts appear to be the same - ATIRadeonX1000 and ATIRadeonX2000.

(Note: I was at least able to achieve framebuffer functionality with my HD 3870 on 10.6, using Chameleon which has a built in framebuffer injector, however this too does not work on the HD 2400, and I was never able to achieve 3D acceleration - the display would garble, which I think indicates another framebuffer issue, but I couldn't say for sure.)

So essentially...

I think I'm really close to making this work, but I don't think there are any easy answers anymore - I'm going to have to figure out how real framebuffer patching works. Frustratingly, we have current methods that are so close to working, but are just not quite fully correct, which is probably why the more manual WhateverGreen process is recommended now over "easy" solutions like Natit.

To an extent, it seems like we'll have to work it out two separate times: once for 10.6+ and once for 10.4/10.5. The core information will almost certainly be transferable, but the methods will probably have to be different. It may be worth tweaking some of those Natit settings just to see what happens. Unfortunately, I can't find any existing information about getting the HD 2400 working with WhateverGreen, and there's a chance it may not be possible at all since WhateverGreen doesn't guarantee functionality with non-UEFI BIOSes (while it's a virtual machine that could have UEFI, HD 2400 has no support for it, forcing me to use BIOS booting).

So essentially, I think the only step forward is to get into the real nitty gritty of it. I will update here if/when I find any more information.
User avatar
MattKC
Site Admin
Posts: 323
Joined: Mon Aug 22, 2022 1:05 am
Contact:

Re: Figuring out Mac OS X 10.4-10.6

Post by MattKC »

Was curious what I'd get if I swapped back to the HD 3870 right now.

Indeed, as before, I get the best results out of Leopard, which with Natit worked out of the box (the device ID 0x95011002 is already listed in ATIRadeonX2000). No flickering either, so this is actually a pretty solid result.

Tiger's framebuffer worked with the ATY_Megalodon kext I transplanted from 10.5.8 earlier, however I didn't have as much luck with ATIRadeonX2000. Forcing the device into Tiger's ATIRadeonX2000 Info.plist caused a slightly garbled display, and transplanting led to linker/load issues (as expected from transplanting between major versions). I was told the HD 3870 could be made to work on Tiger, and I guess framebuffer-wise that's true, but if I can't get QE/CI too, I consider it a dealbreaker. I have seen a MacRumors thread that involves successfully transplanting ATIRadeonX2000 from Leopard to Tiger to get it running on a MacPro3,1, so that might be worth exploring.

With Snow Leopard, I interestingly got the same behavior I alluded to getting with Chameleon in the OP. Framebuffer works, but garbled hardware acceleration. I wonder if this works against my theory of the framebuffer being the issue, or perhaps Chameleon just happens to do exactly the same thing as Natit does. That being said, this card should work on 10.6 if it works on 10.5, because the iMac that had this card supported both. Natit also continues to cause kernel panics despite the "successful" framebuffer injection.



So far, the best result is 10.5 on the HD 3870. It's essentially seamless. A close follow up is 10.4 and 10.5 on the HD 2400, if only I could find a way to get rid of that flickering. 10.6 has been consistently unworkable, but is slightly closer to working on the HD 3870 due to the framebuffer working. Still, I think I'm going to stick to the HD 2400 because that will definitely do 10.4.
huckleberrypie
Posts: 1
Joined: Wed Mar 15, 2023 1:37 am

Re: Figuring out Mac OS X 10.4-10.6

Post by huckleberrypie »

This reminds me of some thirteen or fourteen years ago when I hackintoshed a Core2Duo rig I had around that time. I was using an 8400GS and later a GT 240 at the time, and the main difficulty was more with getting standby/sleep than with anything else.
User avatar
Wam
Posts: 26
Joined: Thu Dec 08, 2022 12:55 pm

Re: Figuring out Mac OS X 10.4-10.6

Post by Wam »

Figured I'd throw in my own testing here given we've both been trying to work this one out.

My card is an ATI Radeon HD 2600XT. A card that was available for Mac Pros. Importantly this is not to be confused with the ATI Mobility Radeon HD 2600XT which shipped in some iMacs.

Naturally much like Matt's card mine is a PC card configured differently to the Mac version. My card uses GDDR4 memory and has a 64K ROM, meanwhile the Mac card has GDDR3 memory and uses a 128K ROM. This also means I can't just, reflash the card to use a Mac BIOS because one is double the size of the other.

I haven't (yet) been able to test versions of OS X pre-10.6. Given I'm testing with real period hardware (a Dell Inspiron 530 w/ a Q6600), testing multiple versions gets complicated quickly.

Before we get into the operating systems themselves though, I wanna talk about framebuffers. Framebuffer configuration for this card is annoying. I've had to experiment around quite a bit. Using Clover I've been able to change the device's PCIe ID (which I shouldn't need to do? 0x95811002 is already in ATIRadeonX2000.kext...) and framebuffer codename. From snooping around in the motherfucking CLOVER SOURCE CODE there's a commented out section detailing display name, PCIe ID and Framebuffer configuration for my card. From this I've been able to gather that the framebuffer type I should be using is Hypoprion, but some appear to use Lamna? We'll get to that...

With Snow Leopard, the card is only functional in Safe Mode, at which point it is detected perfectly and resolution changing seems to work fine too. However when booting into the OS proper, what I get depends on the framebuffer configuration I use.

Hypoprion gets me... absolutely fucking nothing lmao. Literally nothing at all. No picture. Sometimes not even a signal on any DVI port. The GPU just, gives up.

Lamna on the other hand nets me...
427D9690-4AED-4501-839C-2BC32413EC79.jpg
It's a display... I guess. This kind of graphical corruption almost made me think my GPU was just, dead, until I saw Matt getting something similar semi recently.

So I also wanted to test more modern versions of macOS to see if that would change anything? So I tested on both 10.9 Mavericks and 10.11 El Capitan and it does change a little but, not much. Hypoprion continues to not function, but Lamna gets me a cursor. No display corruption, but also nothing but a cursor. You can tell that the OS is running behind that cursor because you can still interact with UI elements, but nothing else renders.

It feels SO close, yet equally so far. I've heard reports that my card simply cannot run in Snow Leopard and presumably nobody tried it on anything higher, but that feels like quitter talk to me? Unfortunately a good lot of the info on these cards is lost to time, and the majority of the people who do know almost definitely either don't care or would rather not be bothered with these kinds of problems.
User avatar
MattKC
Site Admin
Posts: 323
Joined: Mon Aug 22, 2022 1:05 am
Contact:

Re: Figuring out Mac OS X 10.4-10.6

Post by MattKC »

Great info, it's definitely interesting how much our experiences line up. Makes me think this should absolutely work,
Wam wrote: Wed Mar 15, 2023 1:51 am It feels SO close, yet equally so far. I've heard reports that my card simply cannot run in Snow Leopard and presumably nobody tried it on anything higher, but that feels like quitter talk to me? Unfortunately a good lot of the info on these cards is lost to time, and the majority of the people who do know almost definitely either don't care or would rather not be bothered with these kinds of problems.
Yeah I don't buy that it's not possible. While there are clearly some framebuffer differences introduced in 10.6, there's no indication that these cards suddenly became unsupported.

I think it's more a matter of no one has bothered to figure it out before.
User avatar
MattKC
Site Admin
Posts: 323
Joined: Mon Aug 22, 2022 1:05 am
Contact:

Re: Figuring out Mac OS X 10.4-10.6

Post by MattKC »

So I've learned a little bit more how Mac OS X graphics work. These shark names actually refer to "framebuffer personalities", and one of the biggest parts of the framebuffer personality is the "connectors", i.e. what ports the GPU has (since this is the late 2000s: DVI, VGA, S-video, etc.)

"Helpfully", Apple has hardcoded these into the kexts, because they can, which is what makes framebuffer injection necessary. These hardcoded connectors often need to be replaced to fit the hardware, and apparently incorrectly defined ports is one of the primary causes of "blank screen" syndrome.

The ports are defined as 16-byte ConnectorInfo structs in the kexts. Apparently in early versions of 10.6, these are all in ATIFramebuffer, but in later versions they got separated out into the ATIxx00Controllers (in even earlier versions like 10.4-10.5, it's a different sized struct in the ATINDRV/ATIRNDRV plugins, which might explain at least some of the differences between versions I mentioned in the OP). By looking at these, I've learned some pretty interesting stuff:
  • Iago, the personality in ATI2400Controller (and most commonly ascribed to the HD 2400), only has two connectors. One is an LVDS connector, and the other is a type that no one seems to have documented. Considering this pre-dated widespread adoption of DisplayPort, the LVDS connector is probably an internal connector, most likely for an iMac. This would probably make the other port the iMac's external mini-DVI port. This could explain why I get a black screen with this card, neither of these ports really line up with what's actually on the card.
  • Hypoprion and Lamna, the two personalities in ATI2600Controller, also both have two ports. Hypoprion actually has the same exact ports as Iago, so (assuming my theory is correct) that must also be the iMac version of this card. Lamna on the other hand defines two DVI ports, one single-link and one dual-link. That must be the one from the Mac Pro, and would explain why Lamna actually gives you an output.
  • Megalodon is one of two personalities in ATI3800Controller (the other being Triakis). Megalodon has 3 ports, a single-link DVI, dual-link DVI, and an S-video port (Triakis is the same as Megalodon but without the S-video port). This actually lines up pretty well with my ATI cards (both my 2400 XT and 3800), and may in fact be why that personality happens to produce an output with both of my cards. But since it's otherwise designed for the HD 3870, that may be the cause of the flickering I get with the 2400. Perhaps if I used the Iago personality but hex edited the personalities to match the card, I would get a functional output?
I'm not entirely sure what this tells us outside of answering a few questions, though that doesn't necessarily answer yet why we're getting garbled display on 10.6 with 3D acceleration enabled.
User avatar
MattKC
Site Admin
Posts: 323
Joined: Mon Aug 22, 2022 1:05 am
Contact:

Re: Figuring out Mac OS X 10.4-10.6

Post by MattKC »

MattKC wrote: Sat Mar 18, 2023 5:03 amPerhaps if I used the Iago personality but hex edited the personalities to match the card, I would get a functional output?
Holy shit this actually works! If I transplant the DVI connectors from Megalodon into Iago, I get full resolution output from Snow Leopard! (with no flickering too!)

I still need injection to pair my GPU with the "ATY,Iago" personality name, but I've ported this to a pure OpenCore approach (rather than injector kexts like Natit and ATIinject). If you're curious, this is the code I'm using to do the injection in OpenCore's config.plist:

Code: Select all

<key>DeviceProperties</key>
<dict>
  <key>Add</key>
  <dict>
    <key>PciRoot(0x1)/Pci(0x2,0x3)/Pci(0x0,0x0)</key>
    <dict>
      <key>@0,AAPL,boot-display</key>
      <data>AQAAAA==</data>
      <key>@0,ATY,EFIDisplay</key>
      <string>TMDSA</string>
      <key>@0,compatible</key>
      <string>ATY,Iago</string>
      <key>@0,device_type</key>
      <string>display</string>
      <key>@0,name</key>
      <string>ATY,Iago</string>
      <key>@1,compatible</key>
      <string>ATY,Iago</string>
      <key>@1,device_type</key>
      <string>display</string>
      <key>@1,name</key>
      <string>ATY,Iago</string>
    </dict>
  </dict>
  <key>Delete</key>
  <dict/>
</dict>
The most challenging part of this was getting the PCI address of the graphics card. To do so, I used gfxutil, specifically version 1.76b whose binary works in Snow Leopard out of the box (it seems you can compile it manually down to 10.4, but I had no luck). The command to get the GPU's PCI address is:

Code: Select all

gfxutil -f display
I also needed to modify ATI2400Controller's Info.plist to match my card's device ID (94c3 instead of Apple's variant which is 94c8), but it does get the framebuffer working, and with no flickering! I have a feeling if I could do the same transplant on 10.4/10.5's ATY_Iago, it may work perfectly (since 3D is already confirmed working). However, so far my attempts to do so have proved fruitless (the kexts are very differently laid out pre-10.6 rewrite, and while I found data that I'm pretty sure is the connector table, transplanting it has not worked so far).

I can confirm that this works on Lion and Mountain Lion though. Overall it's a somewhat involved process to transplant connectors and edit the Info.plist for each OS, but I have a feeling I could roll the whole thing into an OpenCore patch so it would work universally. 3D still doesn't work on 10.6+ so this hasn't solved that yet.
User avatar
MattKC
Site Admin
Posts: 323
Joined: Mon Aug 22, 2022 1:05 am
Contact:

Re: Figuring out Mac OS X 10.4-10.6

Post by MattKC »

Update: For shits and giggles, I ended up installing every single version of Mac OS into this VM that can theoretically support my HD 2400:
everymac.png
Partly this was an exercise to see whether I could get my OpenCore configuration compliant enough (which I eventually did), but also I thought it would be useful to see if other versions behaved any differently.

If you're interested in seeing how I got every version to boot:
There are two major things that I needed to cover to get all of these versions working. 10.4-10.5 require HPET at the kernel level, which QEMU doesn't emulate by default, leading to an immediate reboot/restart as the kernel fails to load. On real hardware, HPET fixing can be a fairly involved process, but in virt-manager, it's thankfully as easy as adding this to the XML (under "clock"):

[code]
<timer name="hpet" present="yes"/>
[/code]

Alternatively, a lot of "distros" from this period simply use a patched kernel that removes the HPET requirement entirely.

All versions from 10.7 onwards have a different issue entirely due to a very obscure quirk introduced in QEMU 6.1. A feature was added to the PCI-e implementation that "altered the ACPI tables presented to the guest VMs". Mac OS doesn't seem to like these changes at all, which on my end manifested in the bootup freezing at "PCI Configuration Begin". This seems to be particularly problematic with virt-manager because it enforces a correct PCI-e layout while raw QEMU doesn't.

This can be solved by either using a version of Q35 older than 6.1 (i.e. setting the machine type in the XML to "pc-q35-6.0" or lower), or disabling the problematic feature by adding the following to your XML:

[code]
<qemu:commandline>
<qemu:arg value="-global"/>
<qemu:arg value="ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off"/>
</qemu:commandline>
[/code]
The HD 2400 is (at least technically) supported from 10.4 Tiger all the way to 10.13 High Sierra. If you're thinking "wasn't that also the last version to support NVIDIA?" then you're right! And it's for more or less the same reason; it seems with 10.14, Apple rewrote the UI to be entirely Metal 2 rather than OpenGL (also deprecating OpenGL entirely in the same version), and "conveniently" neglected to supply NVIDIA with the documentation to write a driver for Metal 2. They also (understandably) felt that writing new Metal 2 drivers for geriatric GPUs like the HD 2000 series was unnecessary. But up until that change, the HD 2000 series was indeed officially supported.

That being said, I don't think anyone has actually managed to get these to work. Whether it's 10.4/10.5 (where the framebuffer doesn't seem to work) or 10.6+ (where QE/CI seems to break it), I can't see any evidence of anyone ever achieving a reliably functional setup.

I've seen a handful of people say they got the ATI Mobility Radeon HD 2400 (laptop variant) to work on 10.4/10.5, and while laptops are usually a little worse for hardware compatibility, this actually doesn't surprise me at all. As I mentioned earlier, the Iago personality (most likely designed for early aluminum iMacs featuring an HD 2400) directly specifies an internal LVDS display, which would match perfectly with most laptops. Meanwhile, for the desktop variant, most sources that claim it works end up switching to Megalodon, which works partially but seems to be technically incorrect (and at least for me causes severe flickering; it's still unclear the exact cause of this and none of these other threads seem to mention it).

Meanwhile on 10.6+, many people mention that 3D acceleration breaks it, all with no solution/answer. Notably, this happens not only on the HD 2000 series, but also on my HD 3870, which despite its name, still uses ATIRadeonX2000 for 3D acceleration.

(Interestingly the behavior is slightly different on 10.6 than it is on 10.7+ - on 10.6, the display becomes very glitchy, but on 10.7+ it simply goes white/gray - though a correct cursor appears on both.)

It's funny how the two "graphics revisions" (10.4/10.5 and 10.6+) both have diametrically opposed issues - on 10.4/10.5, the framebuffer is broken but the 3D is perfect, on 10.6+, the framebuffer is perfect but the 3D is broken. Unfortunately, I don't really know what that tells us. The conclusion I want to make is that the framebuffer is simply broken on all of them, and that somehow if it was right, the 3D would be fixed on 10.6+ too. But the fact that so many people ran into the issue (and the fact that the framebuffer is otherwise perfect in 10.6+) makes me wonder if it really is just an issue introduced to ATIRadeonX2000. That being said, I'm not sure what that issue could be. After all, it's not like the hardware in the iMac7,1 magically changed, so how differently can the software be driving it?

One of the threads linked above theorizes that, since OpenCL was introduced in 10.6, the issue is ATIRadeonX2000 and/or Mac OS trying to initialize OpenCL for cards that don't support it. This doesn't sound implausible, however I've opened ATIRadeonX2000 in Ghidra and have found nothing to confirm or deny that. It's also not clear how this would break the UI, which shouldn't be using OpenCL in any way, but that doesn't necessarily disprove it.

I have also played around with WhateverGreen, considered the "correct" way to do framebuffer patching nowadays, however it does nothing out of the box (and looking at the code, only seems to support ATIRadeonX3000 and up, no X2000). Ostensibly, you're supposed to write an SSDT to configure it, which I tried, but ran into issues with QEMU's ACPI implementation not giving me the paths required to even write an SSDT for the GPU in the first place (depressingly, with the above "problematic QEMU feature" enabled, I do get the paths I need, but then Mac OS doesn't boot so it doesn't help at all). Compounding it is that WhateverGreen themselves don't provide a ton of documentation for how to do this, and almost certainly wouldn't be willing to help at all (they quite explicitly provide zero support, even insisting that you "avoid asking any questions"). For now, this feels like a bit of a deadend.

So tl;dr, not really a ton of progress, but some new information. It would seem to get any further I'll need to reverse engineer 10.4/10.5's ATY_Iago and/or ATY_Megalodon, and/or 10.6's ATIRadeonX2000 and hope they shed some light on what exactly is going wrong.
User avatar
Wam
Posts: 26
Joined: Thu Dec 08, 2022 12:55 pm

Re: Figuring out Mac OS X 10.4-10.6

Post by Wam »

MattKC wrote: Thu Mar 23, 2023 4:19 am One of the threads linked above theorizes that, since OpenCL was introduced in 10.6, the issue is ATIRadeonX2000 and/or Mac OS trying to initialize OpenCL for cards that don't support it. This doesn't sound implausible, however I've opened ATIRadeonX2000 in Ghidra and have found nothing to confirm or deny that. It's also not clear how this would break the UI, which shouldn't be using OpenCL in any way, but that doesn't necessarily disprove it.
Here's a thing we can use to disprove this pretty quickly.

ATI released a Mac version of the HD 2600XT and other cards that use ATIRadeonX2000.kext, which obviously being the same generation (and the exact same physical die as the PC versions of the cards) also don't support OpenCL. They don't exhibit this behaviour. OpenCL, being a client library, shouldn't be initialized until it's requested by an app that's using it? And what would a compositor be doing with it? Especially when Apple released Snow Leopard in 2009 for a plethora of Macs with GPUs that have no hope of ever running OpenCL code?

It just doesn't make sense. This theory to me at least seems like people heard OpenCL, went "oh that sounds like OpenGL and is GPU related and therefore must be the cause of all of our problems".
User avatar
MattKC
Site Admin
Posts: 323
Joined: Mon Aug 22, 2022 1:05 am
Contact:

Re: Figuring out Mac OS X 10.4-10.6

Post by MattKC »

Much later update: I now feel pretty convinced that this never worked.

Everyone I've seen who managed to get an HD 2xxx working on 10.6+ says they simply deleted ATIRadeonX2000, forgoing any QE/CI at all:

Screenshot_20230617_104534.png

I found this blog post by Netkas, one of the most prominent Hackintosh developers from the early era, who confirms that QE/CI stopped working for HD 2xxx/3xxx in Snow Leopard, and follows up in a 2011 comment saying there's nothing that can be done, it just "will not work". Indeed, even his then-tentative solution is to just delete ATIRadeonX2000.

The idea that it's OpenCL indeed seems to be a common misconception that started with another Netkas blog post explaining why Snow Leopard's OpenCL implementation won't work on Radeon 2xxx/3xxx cards (including the ones that shipped with iMacs and Mac Pros). Notably, it doesn't mention anything about QE/CI, but it seems people just assumed they were related because they were looking for any reason why 2xxx/3xxx cards stopped working. Netkas actually had to clarify this in another thread, that QE/CI has nothing to do with OpenCL, and that the Snow Leopard problem is "about opengl, smth wrong with loading textures into card, or smth similar", which is pretty much what we concluded too.

No further progress ever seems to have been made. Netkas alluded that he was looking into it, but never seemed to find a solution. To be fair, back then QE/CI wasn't as necessary on OS X as it later became, but it's still a shame that this card essentially never became any more useful than a standard VESA card, despite theoretically being fully supported until at least 10.11 (some sources say 10.13).

So essentially the crux of this issue and the only way to solve it is to figure out: how come Apple's variants of these cards (the 2400 XT in the iMac8,1 and the 2600 XT in the MacPro3,1) don't have this issue? What do they do differently that the PC variants don't do? I would be really curious to know, though I have no idea if I'll ever end up figuring it out (as I've said in other threads, there may be better uses of my time).
Post Reply