xmrig / xmrig-cuda

NVIDIA CUDA plugin for XMRig miner
GNU General Public License v3.0
358 stars 155 forks source link

Instructions for compiling on macOS, please? #107

Closed jeremyelgin closed 1 year ago

jeremyelgin commented 3 years ago

I'm flying blind here, don't know whether I should have (only) Xcode installed or do I need Homebrew (from reading other compilation instructions)? If I get this going, I'll give it a go...

Spudz76 commented 3 years ago

CUDA ended support for anything newer than 10.13 (High Sierra)

So step one is downgrade to 10.13, install Homebrew (which installs Xcode) and some other deps like bash, autoconf, automake, libtool... and then follow the CUDA Toolkit 10.2 Installation Guide for Mac

Then build this plugin. Then build the main miner app, which requires usage of the scripts/build_deps.sh because brew on 10.13 doesn't work for some of the deps anymore, and brew is not concerned with whether unsupported 10.13 still works (although it still mostly does).

I know of no way to install CUDA 10.2 on newer MacOS but allegedly it does not work at all. There exist no newer releases of CUDA since Apple wants everyone to use Metal.

jeremyelgin commented 3 years ago

Thanks Spud.

Seems like a huge headache for a dead-end... Does anyone know whether a Metal plugin would be feasible then?

Spudz76 commented 3 years ago

OpenCL works, but would be slower than CUDA (probably, it is slower on every other platform...) There is an issue over in the main xmrig/xmrig project that turned into getting MacOS OpenCL to work better -- it doesn't work very well at all without the patches, which haven't been completed and submitted for merging yet. That would probably at least be close to working (if not fully working) and you'd be the first test of an nvidia GPU (so far tested the M1, Intel, and some AMDs).

Nobody has bothered to attempt writing miner kernels in Metal, an API that only works in one OS. Didn't do it for Vulkan-Compute either and that supports more platforms, mostly things where OpenCL currently works fine (not sure if it would be faster or even possible).

The Apple OpenCL in recent releases just converts functions to Metal calls (cl2metal subsystem) so in a way it already runs on Metal. Maybe the translation layer isn't so bad at translating (once you get all the OpenCL stuff to match standards and not leverage AMD-only extensions and shortcuts everywhere) and then native-Metal kernels may not really gain anything, while taking quite a bit of effort to create.