search

lnxd / docker-phoenixminer

Containerised version of PhoenixMiner for AMD GPUs. Helps turn your Unraid server into an Ethereum / cryptocurrency mining rig. Contains AMD drivers. Not affected by the AMD reset bug as it doesn't rely on vfio.
2 stars 12 forks source link

amdgpu proprietary driver #33

Open jmpolom opened 2 years ago

jmpolom commented 2 years ago

This is perhaps not actually an issue but a question about the design choices made when packaging PhoenixMiner in a container.

Why is the AMD proprietary driver installed with the start.sh script as opposed to being installed during the container build process (IE: in the Dockerfile)? In the past the Dockerfile installed the driver and it was built into the container image.

Very curious what led to the change here. Looks like it was commit b633540a434e729888df5f823c10a7c538964856 where the Dockerfile no longer installed the AMD proprietary driver.

lnxd commented 2 years ago

Hey there,

That's exactly right yeah. To change the behaviour, you're always more than welcome to add the specific lines back into the Dockerfile and then push it to Dockerhub yourself. You could automate it using sed commands as well to get the latest updates (I do this locally when I'm working on it). Originally I had a different tag on Dockerhub for each driver version PM relied on, but it was too much work maintaining the compatibility list and all the different builds. So I'm sorry about that, I'm just really strapped for time. Actually it was only a week or two ago that I deleted the last tag with the most widely compatible drivers built in because it had no pulls for several months and meant twice the testing on each push.

There's several reasons that led me to make this change:

  1. The primary reason: PhoenixMiner isn't perfect. Different versions of PM use different drivers to support different cards, and different driver versions can behave very differently depending on the version of PM as well. To make matters worse, the PM devs don't keep their change log history public, nor an archive of old versions, and archive.org hasn't got the entire history. So having it this way makes user debugging possible; I have enough time to push out updates when the PM devs do but not necessarily enough time to help users work out why the PM update broke their otherwise perfectly working setup for no identifiable reason 😂.
  2. It's more consistent with the way the Nvidia install script works. This container was originally developed to be used with Unraid, which is probably the best use scenario unless you have another reason to isolate the PM binary on a system. I still hope AMD changes their drivers to work in a more similar fashion to Nvidia but it's very unlikely. Funny enough the way AMD cards and drivers function is the reason I had to make this container in the first place.
  3. From a development perspective, having/not having the drivers installed at build time greatly impacts the time it takes to comprehensively test a minor update or change, for this reason I have different build scripts locally.

Originally I was planning on making it possible to selectively install PM versions as well, I have a prototype of this working on my local Gitea instance (for lolMiner as well) but it's very dangerous in the event that the PM developer's website / Bitcoin Talk account gets hacked or they somehow go rogue, and the PM developers also went through a period where they changed between 3 different download hosts in a week (Mega -> Github -> phoenixminer.info); can't rely on them to stay consistent.

Just mentioning in case it's reinstalling the drivers on every launch, if that's happening there's either something wrong with the current build of this container or something wrong with the environment you're running it in. To note, I no longer use this container personally, I just maintain it because I wrote it and it seems to have a few users that rely on it.

jmpolom commented 2 years ago

Wow. Lots of great info in your response. Wasn’t expecting to get all of that. I was looking into packaging folding@home into a container that supports AMD GPUs and recalled this project being perhaps an example of how that could be done. It looks like there’s already an F@H container that might support my setup via ROCm but I have not yet gotten to test it.

I’m glad to hear that the choice to install the proprietary AMD driver was driven mostly by PM being finicky and not by the GPUs having unique requirements themselves. Definitely sounds like PM presents some serious packaging challenges when it comes to ensuring proper support for various AMD GPUs. I do have to wonder if folding@home is more forgiving in this department or not.

It's more consistent with the way the Nvidia install script works.

I looked through the build script and noticed that you were installing an nvidia driver inside the container as well. I was a little confused by this since typically for containers with nvidia devices, I don’t believe you need to have the driver installed locally in the container. What is the purpose of installing the nvidia driver package inside the container? I wasn’t aware that would actually work to enable a container to access an nvidia GPU.