2026 Hardware Audit: Debunking the FP64/OpenCL Barriers for Apple Silicon

[Ncard00]

For several years, the exclusion of Apple Silicon iGPUs from the Folding@home whitelist has been justified by the claim that macOS lacks stable OpenCL support and that the M-series chips cannot handle the high-precision FP64 math required for scientific folding.

As of early 2026, these technical excuses are no longer grounded in reality.

The landscape has changed significantly, and the "Old Guard" arguments are being directly contradicted by the success of other major distributed computing projects:

Proven FP64 Stability:

Projects like Einstein@Home and PrimeGrid have successfully deployed iGPU applications for Apple Silicon.

These projects are running complex, high-precision scientific searches on M4 hardware right now with 100% stability.

If these projects can perform deep-space and prime-number math on the M-series GPU, the claim that F@H cores "can't" is mathematically and technically incorrect.

GROMACS Native Support:

GROMACS, the very engine that F@H relies on, has officially modernized its codebase to include native support for Apple Silicon GPUs.

The underlying infrastructure is already there; the barrier is now purely administrative within the F@H whitelist process.

Efficiency Gap:

By keeping the M-series blacklisted, we are forcing Mac users to fold on their CPUs, which is objectively less efficient.

My base M4 Mac Mini can handle intense parallel workloads on the iGPU at a fraction of the power draw of a traditional desktop card.

We are effectively blocking the most "Green" compute nodes in the world.

The hardware is ready, the engine (GROMACS) is ready, and the proof of concept has been established by every other major scientific project in the space.

It is time to stop the "deprecated OpenCL" debate and move toward an experimental whitelist for the M-series iGPU.

Let’s stop leaving this massive pool of high-bandwidth, energy-efficient silicon on the sidelines.

Can we get a status update on when the whitelist will be updated to reflect the reality of 2026 hardware?

[calxalot]

Please post in github:

https://github.com/FoldingAtHome/fah-cl ... issues/303

[calxalot]

See also
viewtopic.php?t=43406

[Joe_H]

For several years, the exclusion of Apple Silicon iGPUs from the Folding@home whitelist has been justified by the claim that macOS lacks stable OpenCL support and that the M-series chips cannot handle the high-precision FP64 math required for scientific folding.

There is nothing false about the OpenCL claims. Apple may "support" OpenCL, but they could announce an end to it at any time. They have deprecated OpenCL in favor of Metal, and that dates back to the release of macOS 10.14 Mojave in 2018. Notably while supporting it on their M-series iGPUs, it is not supported on the CPUs. Apple did manage to break OpenCL shortly after introducing the first Apple Silicon powered Macs, but at least this time patched it fairly quick. Developers remember quite well that Apple had a serious bug in OpenCL about a dozen years ago that prevented F@h and other projects such as those through BOINC from doing GPU processing, it took Apple about 2 years before they released a fix.

There is no FP64 support on the iGPUs, so those calculations need to be done on the CPU. Details differ between OpenMM and GROMACS on how that is handled.

As for you mentioning that GROMACS supports it, up until now all GPU folding cores have been based on OpenMM, not GROMACS. That may change in the future, but you are demanding something they have not done before this time.

So, from what I understand there has been some investigation about this. So far nothing has been released, though supposedly some have volunteered to work on detection code for the client. The iGPU doesn't have a PCI ID like other GPUs being used, so the current method of determining whether a usable GPU is present doesn't work with the M-series processor iGPU sections. Will this result in a client and usable Mac GPU folding core, maybe, maybe not. And I and the others can't give you any idea right now of when or if that will happen.

[Ncard00]

Thank you for the detailed historical context, Joe_H.

I appreciate the clarification regarding the reliance on OpenMM for the current GPU folding cores.

​It is understandable that historical instability in Apple's OpenCL implementation has left a mark on development.

However, my goal in bringing up the M4 benchmarks is to highlight that in 2026, the hardware has outpaced the legacy software assumptions.

While the current client relies on PCI IDs, the move toward unified memory architectures across both Apple and Intel (Panther Lake) suggests that a new detection method will soon be a necessity for the project's long-term "Green" efficiency.

​I will take the technical discussion to the GitHub issue suggested by the moderator.

I look forward to seeing how the v8 client or future OpenMM updates might finally leverage these high-bandwidth iGPU cores.

[Joe_H]

So far all of the Intel processors with iGPUs still have a detectable PCI ID. Same exists for the AMD processors. When or if that will ever change we will find out, but the client detection code still works for them for now.

Don't underestimate stability either. F@h has a fairly small group of software developers to do the GPU cores, so chasing after unstable products can be limited by time availability. I do know the developer they had years ago to create the first GPU core based on OpenMM (Core_17) fully intended to have Apple versions. But during initial testing the Linux and Windows versions ran fine, but they kept getting errors with the Apple version. Eventually that was tracked back to the OpenCL bug I mentioned. By the time Apple fixed it almost no Macs had usable GPUs, and that remained the case for years outside of the few who would upgrade 2010-11 era Mac Pros with third party video cards.

The M-series processor GPUs do look good, and as I mentioned some investigation is going on. But first a decade's worth of lost familiarity with the OS also needs to be overcome. It would be even easier if Apple came right out and gave a timeline on how long they will continue their deprecated support of OpenCL, but I doubt that is ever going to happen. What will happen based on past performance is some developers convention will get an announcement that the next version of macOS will drop support, and that will be it.

[Ncard00]

So far all of the Intel processors with iGPUs still have a detectable PCI ID. Same exists for the AMD processors. When or if that will ever change we will find out, but the client detection code still works for them for now.

Don't underestimate stability either. F@h has a fairly small group of software developers to do the GPU cores, so chasing after unstable products can be limited by time availability. I do know the developer they had years ago to create the first GPU core based on OpenMM (Core_17) fully intended to have Apple versions. But during initial testing the Linux and Windows versions ran fine, but they kept getting errors with the Apple version. Eventually that was tracked back to the OpenCL bug I mentioned. By the time Apple fixed it almost no Macs had usable GPUs, and that remained the case for years outside of the few who would upgrade 2010-11 era Mac Pros with third party video cards.

The M-series processor GPUs do look good, and as I mentioned some investigation is going on. But first a decade's worth of lost familiarity with the OS also needs to be overcome. It would be even easier if Apple came right out and gave a timeline on how long they will continue their deprecated support of OpenCL, but I doubt that is ever going to happen. What will happen based on past performance is some developers convention will get an announcement that the next version of macOS will drop support, and that will be it.

Thank you for the detailed history, Joe_H. I completely understand the hesitation given the OpenCL bugs of the past. However, the landscape in 2026 has shifted significantly.

GROMACS 2026 now explicitly lists Apple M-series OpenCL as the recommended backend for macOS GPU acceleration. If the very engine F@H relies on is now confident enough to officially support it, perhaps the stability concerns of the previous decade are finally behind us.

Regarding the developer bandwidth, I've noticed other projects like PrimeGrid successfully use transparent funding goals to prioritize specific features. Would the F@H team be open to a 'Community Bounty' for an experimental macOS GPU core?

If we can crowdfund a specific goal to hire a contractor or compensate a lead dev for the initial porting work, it moves the project from a 'someday' wish to an actionable roadmap. The hardware is ready, the engine is ready—we just need a path to fund the implementation so this massive pool of high-bandwidth 'Green' silicon isn't left on the sidelines.

[Ncard00]

One more quick point on the efficiency of this platform going forward. Based on the M5 architecture specs we’re seeing for 2026, the potential for a green folding lab is huge. The base M5 already delivers over 4x the peak GPU compute performance for AI compared to the M4, and a lot of that comes from the new Neural Accelerators in every GPU core.

If we extrapolate the current M4 throughput to the upcoming lineup, the estimated PPD for a native iGPU core looks like this:

M5 (Base): ~1.2 Million PPD M5 Pro: ~2.8 Million PPD M5 Max: ~5.5 Million PPD M5 Ultra: ~11.5 Million PPD

At a predicted 50W system draw for the M5 Mini, we’d be looking at over 20,000 PPD per Watt. The M5 Ultra could essentially replace an entire rack of older 150-200W cards with a single 160W Mac Studio. By the time M6 arrives with the 2nm process in late 2026, the efficiency gap will be even wider. It seems like the perfect time to get a macOS GPU core on the roadmap so this hardware can actually be put to work for the project.

[Joe_H]

Unfortunately that improved performance for AI does nothing for F@h as it is all in low accuracy Neural Engine calculations, INT8, FP8, and so on. The improved communication pathways will help some, but the bulk of the calculations F@h uses are FP32. There is no similar speedup in that, but it is improved a bit from reports.

[calxalot]

The next cpu core uses gromacs 2025.something.