Page 1 of 1

Would FAH work on a RockPro64?

Posted: Fri Apr 05, 2019 7:25 am
by Theodore
First off, the RockPro64 is ARM based.
But it has a PCIE 4x slot.
Image
I know Ubunut runs on many ARM devices already.
But RockPro has a precompiled list of all kinds of operating systems that would work on this board, including Debian, Ubuntu, Slackware and Fedora, and more..., in both 32 and 64 bit flavors; for ARM.

NVidia currently has driver 390.116 out for ARM(32 bit).
The PCIE 4x slot, can be equipped with a "PCIE 4x to 4x PCIE 1x" splitter, to potentially drive up to 4x GPUs
Image
The system costs $75, and I'm willing to give it a try; as my current Rosewill case is still quite bulky, despite me having been able to cram 2x graphics cards in it. A blower type RTX 2070, and a naked (just the board, heat sink, and fans) RTX 2060, that run quite hot inside the small device (80C at 150/130W)
Image



My only question is, if there's a possibility FAH would be able to run on an ARM system, driving GPUs, not from CPU.

Re: Would FAH work on a RockPro64?

Posted: Fri Apr 05, 2019 7:34 am
by Joe_H
No, the folding cores for both GPU and CPU folding are compiled to run on x86/AMD64 processors.

Re: Would FAH work on a RockPro64?

Posted: Fri Apr 05, 2019 7:49 am
by Theodore
Joe_H wrote:No, the folding cores for both GPU and CPU folding are compiled to run on x86/AMD64 processors.
1- Are we talking about FAH would totally not install on an ARM device? Or FAH could, but wouldn't perform as well?
2- Is there a possibility to run FAH through some sort of emulation on these OSes, to emulate an X86, while driving GPUs, or is this idea too far fetched?

Re: Would FAH work on a RockPro64?

Posted: Fri Apr 05, 2019 8:08 am
by JimboPalmer
One of the OSs is Android; there is an ARM Android F@H client developed by Sony. In Android, it would work to the extent it acted like a Sony smartphone. (the F@H client dislikes big.LITTLE processing, which that board features)

https://en.wikipedia.org/wiki/ARM_big.LITTLE

https://developer.sony.com/posts/foldin ... en-source/

Re: Would FAH work on a RockPro64?

Posted: Fri Apr 05, 2019 8:25 am
by Joe_H
1. The regular client would not even install
2. Folding on a CPU might work in emulation, but I have no idea how well an ARM processor would run x86/AMD64 code. As for GPU folding, a number of persons have tried to get that done from within a VM, no one has reported success.

Re: Would FAH work on a RockPro64?

Posted: Fri Apr 05, 2019 9:15 am
by Theodore
True, a VM usually doesn't have direct access to the GPU.

The first option would probably be to try to run the x86 Linux FAH program through ExaGear Desktop. (though they currently claim to be 'sold out'. How can one sell out software, is beyond me :| )
They claim "ANY" program would work; which would remove the 'VM' or Wine layer from the equation, and would supposedly be several times faster too.
But not a lot of info out there on how well FAH would work through it, and/or any mention on GPU driver issues.
Most programs seem to retain the same '80%' performance on ARM as what older technologies promised.
From what I'm finding online, it seems like someone is trying to keep x86 to ARM conversion programs off the market.


The second option, could be to run the windows client through Wine (Compatible with ARM Linux), qemu (or if you can still get your hands on Exagear's Windows emulation layer).
Not sure if all have access to GPU info there either.
But a good start would be to see if the x86 Windows client can run on an X86 Linux system through Wine or qemu.


The third option is Android with Sony Client; it might be possible to assign only the bigger CPU cores.
The problem there, is if the Sony client features GPU acceleration?
The CPU will only be needing to pass data to the PCIE port(s).

Re: Would FAH work on a RockPro64?

Posted: Fri Apr 05, 2019 8:45 pm
by JimboPalmer
While, in theory, any OpenCL driver should work, I do not think F@H has any GPU WUs that do not need a AMD or Nvidia card on x86 CPUs.

I suspect that means the Android client is only using ARM CPUs. (I have not read the code to see if it uses more than one CPU per device)