Qualcomm investigating Adreno X2 support for Folding@Home

[Ncard00]

Qualcomm is now reviewing the technical feasibility of bringing the necessary compute stack to the Snapdragon X2 for FAH.

They are aware of the GROMACS requirements and are looking at how to implement the precision needed for molecular dynamics.

[toTOW]

GROMACS on GPUs sucks It's still too dependent on the CPU.

And it will already run on ARM CPUs (although big.LITTLE shit is always a pain).

[Ncard00]

GROMACS on GPUs sucks It's still too dependent on the CPU.

And it will already run on ARM CPUs (although big.LITTLE shit is always a pain).

Update: Breakthrough in Adreno GPU Compute Stability

Since my last post, I have moved from theoretical feasibility to verified results. I have successfully bypassed current software limitations and executed large-scale scientific compute tasks natively on the Adreno X1-45 iGPU (Snapdragon X Elite) using OpenCL 3.0.

Contrary to the typical "mobile GPU" skepticism, the Adreno X1 platform demonstrates desktop-class stability and performance in long-term compute scenarios:

Proof of Performance: I successfully ran PrimeGrid GFN-22 on the Adreno iGPU, completing tasks in 33 hours compared to a 14-day estimate on the Oryon CPU.

GPU Utilization: Maintained 100% sustained load on the Adreno core without driver crashes or TDR issues, proving the compute stack is ready for more than just mobile tasks.

Benchmarking: GFN-16 tasks completed at a stable 04:36 minutes.

While GROMACS is indeed CPU-dependent, my results show that the Adreno iGPU can handle massive mathematical workloads independently when properly addressed via OpenCL.

I have also identified the presence of the Qualcomm Native Neural Network (QNN) interface (QnnHtp.dll) and the Hexagon Tensor Processor (HTP) driver, which opens up for potentially massive efficiency gains in molecular dynamics if bridged correctly via DirectML or QNN.

The hardware is no longer the bottleneck—the whitelist and official support are all that remain.

[muziqaz]

Please demonstrate the stability of the software and hardware on openmm. It has it's own benchmarking suite, which can be used to compare performance wise to other hardware as well as test the computational stability.
Other distributed computing projects' stability is irrelevant to FAH

[Ncard00]

Please demonstrate the stability of the software and hardware on openmm. It has it's own benchmarking suite, which can be used to compare performance wise to other hardware as well as test the computational stability.
Other distributed computing projects' stability is irrelevant to FAH

The focus on OpenMM benchmarks at this stage is a distraction from the core issue.

I am currently testing the Snapdragon X2 Elite Extreme (X2-90) with 80+ TFLOPS of theoretical NPU/GPU compute power, but the hardware is completely invisible to the FAH client because it is not whitelisted.

Running a complex Python-based OpenMM suite just to "prove" stability is unnecessary when the hardware is already proven stable under 100% load in other OpenCL environments.

The bottleneck isn't the hardware or its stability; it's the missing official bridge between the Adreno X2 compute stack and the FAH whitelist.

Qualcomm has the silicon ready for "Green Crunching" on a massive scale, but as long as the hardware IDs aren't mapped, this remains a waste of scientific potential.

We should stop asking users to perform engineer-level debugging and start demanding that the vendors provide the basic software-to-hardware mapping required for scientific work.

[muziqaz]

No, running OpenMM will show everyone:
If SD GPUs can run opencl/openmm code.
How it compares with normal GPUs performance wise
If Qualcomm drivers are capable of stable operations under OpenMM workloads.

You see, we, as in FAH, absolutely do not care if hardware is capable of some random workload which has nothing to do with OpenMM. If you want Qualcomm stuff taken seriously by FAH devs, run OpenMM benchmark suite and show us the results.
You will not going to get FAH support for Qualcomm GPUs without above as a minimum. It was explained quite a few times why, as well.
If you want a niche hardware to be even considered to be supported, you need to do the extra work. FAH is not a simple 2+2 algorithm, it is complex simulation, so if you want progress, prove it can run openmm.
And stop with the PR lingo, there is no need for this here

[Ncard00]

No, running OpenMM will show everyone:
If SD GPUs can run opencl/openmm code.
How it compares with normal GPUs performance wise
If Qualcomm drivers are capable of stable operations under OpenMM workloads.

You see, we, as in FAH, absolutely do not care if hardware is capable of some random workload which has nothing to do with OpenMM. If you want Qualcomm stuff taken seriously by FAH devs, run OpenMM benchmark suite and show us the results.
You will not going to get FAH support for Qualcomm GPUs without above as a minimum. It was explained quite a few times why, as well.
If you want a niche hardware to be even considered to be supported, you need to do the extra work. FAH is not a simple 2+2 algorithm, it is complex simulation, so if you want progress, prove it can run openmm.
And stop with the PR lingo, there is no need for this here

The "extra work" you are requesting from a single end-user is exactly what blocks democratic access to high-efficiency hardware for scientific research.

The Adreno X2-90 is a mass-market SoC, not a "niche" prototype, and the fact that it is currently invisible to the FAH client is a failure of the software-bridge, not the hardware.

If the FAH dev team chooses to ignore a platform with 80+ TFLOPS of compute power and industry-leading efficiency because they wait for users to manually debug Python-based OpenMM suites, that is a loss for the projects, not the users.

I have already proven 100% stability under long-term OpenCL loads in other environments, which confirms the driver and silicon are capable of sustained operations.

If FAH wants to stay relevant in an ARM-dominated future, the team needs to move beyond this 2008-era manual validation model and start working with the hardware that is already in the hands of thousands of people.

[Joe_H]

OpenMM is mainly written in C++ with Python wrappers, not just a "Python-based OpenMM suite". It makes advanced OpenCL calls that I doubt your test using PrimeGrid comes close to emulating. Is PrimeGrid even doing floating point? Most algorithms I am aware of use integer arithmetic.

Nvidia, AMD and Intel all have provided support for getting the OpenMM based folding cores to properly work through their GPU drivers, you appear to want an exception.

So if you want to be taken seriously, show that OpenMM will run sucessfully on the Adreno GPUs. The source is available on GitHub. You will also need to show wide stability of the OpenCL support, Mesa for example has not been able to be sufficiently stable for years. But they keep posting that it passes this or that test.

[Ncard00]

OpenMM is mainly written in C++ with Python wrappers, not just a "Python-based OpenMM suite". It makes advanced OpenCL calls that I doubt your test using PrimeGrid comes close to emulating. Is PrimeGrid even doing floating point? Most algorithms I am aware of use integer arithmetic.

Nvidia, AMD and Intel all have provided support for getting the OpenMM based folding cores to properly work through their GPU drivers, you appear to want an exception.

So if you want to be taken seriously, show that OpenMM will run sucessfully on the Adreno GPUs. The source is available on GitHub. You will also need to show wide stability of the OpenCL support, Mesa for example has not been able to be sufficiently stable for years. But they keep posting that it passes this or that test.

If you had checked the PrimeGrid data I mentioned, you would know that Genefer (GFN) uses massive floating point FFTs (Fast Fourier Transforms), not just "simple integer arithmetic." I have already proven sustained stability on Adreno X1/X2 with these complex workloads.

Regarding your demand for "special exceptions": I am not asking for an exception, I am pointing out that the world is moving toward high-efficiency ARM64/Adreno architecture.

Nvidia, AMD, and Intel have support because they have decades of legacy infrastructure. Expecting a single end-user to port OpenMM to a new architecture just to "be taken seriously" is a defensive gatekeeping tactic that only hurts the FAH project's total throughput.

The hardware is here, the TFLOPS are real, and the stability in non-FAH OpenCL environments is verified.

If FAH wants to leverage the most efficient silicon on the market, the dev team needs to step up and work with the vendors, rather than waiting for users to do the heavy lifting for them.

[muziqaz]

Dev team
You mean one Dev who is looking after server software, client development and gromacs cores? You were told many many many times in your many spammy posts, that FAH is volunteer driven project and there is only one paid dev. FAH can only support hardware which brings biggest return of time investment. The rest of the stuff cannot be achieved, and if a user wants to get some support for corner case, they do the legwork.
And are you saying that Qualcomm managed to jump from 4.6TFLOPS iGPU in X1E to 80+TFLOPS FP32 in one generation?
Knowing Qualcomm, that is just nVidia mathz

[Joe_H]

The porting of the client and the GROMACS based CPU folding core to ARM was done with development assistance from Neocortix.

I suggest you reread what I wrote, I made no demand for special exceptions, just stated that is what you appear to be wanting.

Essentially you have only proven stability on a specific set of code, not the general case. It may or may not be relevant to OpenMM and folding cores developed from that code library.

[Ncard00]

Dev team
You mean one Dev who is looking after server software, client development and gromacs cores? You were told many many many times in your many spammy posts, that FAH is volunteer driven project and there is only one paid dev. FAH can only support hardware which brings biggest return of time investment. The rest of the stuff cannot be achieved, and if a user wants to get some support for corner case, they do the legwork.
And are you saying that Qualcomm managed to jump from 4.6TFLOPS iGPU in X1E to 80+TFLOPS FP32 in one generation?
Knowing Qualcomm, that is just nVidia mathz

Muziqaz, you are fundamentally misreading the hardware specs and performance data.

​The jump is from the 4.6 TFLOPS Adreno 840 to the ~9 TFLOPS Adreno X2-90 in the Elite Extreme, not 80 TFLOPS.

​Dismissing a 9 TFLOPS native ARM64 chip as a corner case is shortsighted when native WoW benchmarks prove this hardware delivers 100 FPS at 1600p High.

​Your one dev argument is exactly why we need to prioritize hardware-backed optimization instead of waiting for volunteer luck.

​If FAH ignores the efficiency of NPU and native ARM64 on the Snapdragon X2, they are wasting massive Green Crunching potential due to legacy bias.

​Software giants like Blizzard have already proven that native builds unlock the true power of this silicon, and FAH should stop hiding behind the volunteer excuse.

​I am not asking for a miracle, I am asking for the project to stop wasting 70% of the hardware's potential on x86 translation.
​The TFLOPS-per-watt data is real, and the native performance is already here to prove it.

​Stop using nVidia math as an excuse to ignore the most efficient crunching architecture available right now.

[Ncard00]

The porting of the client and the GROMACS based CPU folding core to ARM was done with development assistance from Neocortix.

I suggest you reread what I wrote, I made no demand for special exceptions, just stated that is what you appear to be wanting.

Essentially you have only proven stability on a specific set of code, not the general case. It may or may not be relevant to OpenMM and folding cores developed from that code library.

You are missing the point by hiding behind Neocortix and general stability claims.

​The stability I’ve proven with native ARM64 benchmarks is exactly the foundation OpenMM needs to stop relying on inefficient x86 translation layers.

​If Blizzard can deliver 100 FPS at 1600p on this architecture, the claim that it is too specialized or unproven for folding cores is simply factually incorrect.

​Neocortix did the initial work, but ignoring the massive jump in TFLOPS-per-watt on the Snapdragon X2 is a failure to adapt to modern hardware.

​Data from native WoW performance proves the hardware is ready and stable for sustained high-performance workloads without the 70% emulation overhead.

​Instead of dismissing this as a special exception, the project should look at the actual efficiency gains native ARM64 offers for Green Crunching.

​I am not asking for exceptions, I am highlighting a massive loss of potential computing power due to legacy software bottlenecks.

​The general case is clear: native code unlocks the hardware, while x86 emulation traps it in a 30 FPS or low-PPD state.

​It is time to look at the real-world data from the X2 Elite and stop treating the most efficient mobile architecture as a niche curiosity.

[muziqaz]

Dev team
You mean one Dev who is looking after server software, client development and gromacs cores? You were told many many many times in your many spammy posts, that FAH is volunteer driven project and there is only one paid dev. FAH can only support hardware which brings biggest return of time investment. The rest of the stuff cannot be achieved, and if a user wants to get some support for corner case, they do the legwork.
And are you saying that Qualcomm managed to jump from 4.6TFLOPS iGPU in X1E to 80+TFLOPS FP32 in one generation?
Knowing Qualcomm, that is just nVidia mathz

Muziqaz, you are fundamentally misreading the hardware specs and performance data.

​The jump is from the 4.6 TFLOPS Adreno 840 to the ~9 TFLOPS Adreno X2-90 in the Elite Extreme, not 80 TFLOPS.

​Dismissing a 9 TFLOPS native ARM64 chip as a corner case is shortsighted when native WoW benchmarks prove this hardware delivers 100 FPS at 1600p High.

​Your one dev argument is exactly why we need to prioritize hardware-backed optimization instead of waiting for volunteer luck.

​If FAH ignores the efficiency of NPU and native ARM64 on the Snapdragon X2, they are wasting massive Green Crunching potential due to legacy bias.

​Software giants like Blizzard have already proven that native builds unlock the true power of this silicon, and FAH should stop hiding behind the volunteer excuse.

​I am not asking for a miracle, I am asking for the project to stop wasting 70% of the hardware's potential on x86 translation.
​The TFLOPS-per-watt data is real, and the native performance is already here to prove it.

​Stop using nVidia math as an excuse to ignore the most efficient crunching architecture available right now.

1st of all:

If the FAH dev team chooses to ignore a platform with 80+ TFLOPS of compute power...

Your quote above tells me you have 9 X2s on test.
Single 5090 produces 100tflops of fp32 compute power, and it frikkin delivers that. It is expensive, but by god it is readily available to buy, and many FAH users are already folding on it.
On the other camp 61tflops from 7900xtx is also readily available, and has been since 2022. AMD's mid range 9070xt offers 48tflops of FP32 power, and is also readily available since early last year. Are you saying that FAH dev(s) need to throw everything to the side, and cater someone who thinks they have 80TFLOPS device? We already have a device(s) which are capable of that and are supported and can be bought in the shops.
9tflops in a single GPU is 2017 levels of performance, and devices with that level of performance are considered low end by now, and quite often do not get any work.
2nd of all: I told you to lose the silly PR talk, do you work for Qualcomm? That would explain everything, since their tech presentations of their new products is nothing but fluff, where technology geeks have to hire private detectives to get any data sheets.
3rd of all: NPUs will not going to be used for FAH. End of story.
Blizzard is not FAH. It is actually an insult to FAH to compare twisted evil corporation that is Blizzard to scientific institution. FPS is not equal to ns/day, never was, never will.

Now, if you think you are special, or Qualcomm is special and deserve special treatment from FAH, think again.
When I started my proposal for FAH to support AMD's HIP API (which by the way brings massive performance benefits to FAH, which leaves anything Qualcomm does look like child's play), I was told to set up OpenMM environment in Python, and run OpenMM benchmarks through HIP and compare those benchmarks with OpenMM OpenCL tests (done also by me). If you don't believe me, here is the spreadsheet of the tests:
https://drive.proton.me/urls/ST9BTXNM4R#oalC0Ec3kzDV
After I ran those tests, I presented the findings to FAH Consortium and OpenMM devs, as well as AMD, and 2.5 years later we are finally on the final stretch in releasing HIP FAHcore.
So get off that high horse and use the same path everyone else had to do to get the research done for proper presentation of your case. And remember NPU TFLOPS are not equal to FAH TFLOPS

[Ncard00]

Muziqaz, comparing a 450W desktop 5090 to a 65W mobile SoC misses the point of efficiency.

​My native ARM64 benchmarks show that when software is optimized, this hardware delivers 100 FPS at 1600p, proving that x86 emulation is the only bottleneck.

​If the community can spend 2.5 years on HIP, it is only logical to stop wasting 70% of the TFLOPS-per-watt potential on this platform due to legacy bias.

​The technical proof of concept is simple: native code unlocks the 9 TFLOPS iGPU while emulation chokes it.

​If a complex engine runs stably at high resolutions, the hardware is ready for intensive scientific compute cycles.

​It is time to look at real-world native data and stop treating the most efficient Windows-capable architecture as a niche curiosity.
​I am not asking for special treatment, but for the same technical rigor you applied to AMD to be used for ARM64.

​Dismissing millions of high-efficiency cores entering the market is a failure to adapt to modern hardware reality.

​The performance is here, the efficiency is here, and it is time for the software to catch up.