How In the World Do I Get Numba Roc to Work?

I am running Ubuntu 20.04.3 with latest amdgpu-pro drivers installed (i.e. installed using command sudo -H amdgpu-install --usecase=workstation,rocm -y --vulkan=pro --opencl=rocr,legacy ), and I’ve repeatedly tried to install Anaconda, Numba, and roctools from scratch, but after each try when I test output of numba -s I don’t see my dGPU listed anywhere (it’s a gfx900). And also after each attempt of installing roctools along with Numba, trying to run any script with the statement from numba import roc will error out with the message “cannot import name ‘roc’ from ‘numba’”. What am I possibly doing wrong with my installation attempts???

Hi @tedliosu

I hate to be the bearer of bad news, but according to the release notes of numba 0.54 (Release Notes — Numba 0.54.1+0.g39aef3deb.dirty-py3.7-linux-x86_64.egg documentation)
the ROC part is officially deprecated, so if you are using the most recent version of numba, possibly it is simply not around anymore.

It is likely that you ran into an older version of the docs where ROC is still supported (the numba team is aware that those docs are still easily found online and plans to direct everyone to the up to date documentation, which is now hosted on readthedocs and no longer on pydata.org).

On 0.54 I get:

In [1]: import numba.roc
---------------------------------------------------------------------------
ModuleNotFoundError                       Traceback (most recent call last)
<ipython-input-1-9092bd4e1681> in <module>
----> 1 import numba.roc

ModuleNotFoundError: No module named 'numba.roc'
1 Like

Thank you @Hannes for your help, as I did find that downgrading to Numba 0.53.1 solved my problem. But it’s such a shame though that the devs of Numba decided to drop ROCm support moving forward, as Numba ROC was the only HSA GPGPU python programming framework for AMD GPUs that I could find. I also think it’s a bit unfair given how CUDA support is still being kept as the GPGPU programming “space” is already dominated by Nvidia so much to the point that (at least from what I know/understand) that AMD is basically a second-class citizen within that “space”. Anyway, personal opinions aside, is there any GPGPU HSA python alternative to Numba ROC that you know of which I may be able to use to write GPU-accelerated programs in without having to resort to a framework like PyOpenCL which requires knowledge of at least two different programming languages (e.g. Python and OpenCL C)?

Hi :slight_smile:

First things first: I am nothing more than a user of numba, so take all my views as my own and my information with a pinch of salt.

I understand your frustration about the lack of AMD support, but I think it would be somewhat unfair to blame this on the numba dev team. Resources are limited and I suppose there was just simply no one taking care of the ROC part anymore, which means it had fallen behind the CUDA support a lot.

I think this has lots to do with the fact that nvidia (like them or not) is investing loads of money in ensuring support for their hardware. To my knowledge a lot of the recent CUDA development in numba is driven by a full time developer employed by Nvidia. No one stops AMD from offering the same kind of support to it’s community and userbase.

Unfortunately I am not very aware of GPU frameworks since my only interaction point with GPGPU programming was a couple of days in uni, (and surprise, using the nvidia c++ compiler) so I can’t really offer any alternatives.

This is correct - my primary role at Nvidia is supporting the CUDA target in Numba, and there are various additional contributors to Numba from inside Nvidia.

(Take the following points for whatever you think they’re worth, given my disclosure above :slightly_smiling_face:) It’s not so much that it “fell behind” CUDA support that led to its removal (keeping its functionality static would have been fine, IMO) but the core of Numba moves forward, and this requires the targets to move forward with them - I have been keeping the CUDA target up with the Numba core (and generally aligning it closer with the core / CPU targets) but that didn’t happen with the ROC target, so it simply would have broken anyway.

Thank you for your reply; I suppose my intention wasn’t necessarily blaming the developers of numba so much as simply expressing my frustrations at the current state of AMD GPGPU computing in general. Even ROCm, AMD’s own GPGPU computing platform, has been lagging behind in development as they didn’t even start adding Navi support to the platform until nine months after the original Navi cards were released, as one may see from this comment in the main GitHub issue/discussion regarding gfx10xx/Navi ROCm support. Even as of right now there’s no official Navi support on ROCm as listed on ROCm’s main GitHub README here. (Fortunately AMD provides their own set of proprietary drivers which I am using right now to run OpenCL with unofficial ROCm support on my RX 6800 that I got after making my original post here, but I digress).

Also, my apologies to the devs at numba if my post sounded at all like I was trying to blame them, especially knowing now that AMD isn’t actively contributing even nearly as much to the development of numba as Nvidia is. I suppose I understand more now what Jensen Huang meant when he said that “Nvidia is a software company.”

Anyway, since you don’t know of any Numba ROC alternatives, do you at least have any idea of how long Numba 0.53.1 will be available for on the Anaconda repositories until it gets taken down?

Well, it looks like that the ROC target not keeping up with the Numba core (as @gmarkall had mentioned) isn’t the only problem with the ROC target, as I tried to run a Numba ROC program on my new RX 6800 and I got the following warning/error messages:

'gfx1030' is not a recognized processor for this target (ignoring processor)
'gfx1030' is not a recognized processor for this target (ignoring processor)
'gfx1030' is not a recognized processor for this target (ignoring processor)
[message repeats many times]
'gfx1030' is not a recognized processor for this target (ignoring processor)
LLVM ERROR: Attempting to emit S_LOAD_DWORDX2_IMM_si instruction but the Feature_isGCN predicate(s) are not met

Looks like unfortunately Navi support still hasn’t been integrated into either Numba ROC, ROCtools, or both. Thinking that it might be ROCtools that’s lacking the Navi support, I tried building ROCtools from source using this repository in hopes that I may be manually able to add Navi support to a self-built version of ROCtools. However, I quickly found out that the ROCtools build files relied on such an outdated (and no longer existent) version of ROCm that a major rewrite was required for at least one of the files just to successfully build ROCtools, let alone integrating Navi support into a successful build of ROCtools. Basically, my own efforts to incorporate Navi support into a self-built version of ROCtools went about as smoothly as trying to fit a car wheel onto a ship, at least with the current source code, build files, and build config files on the ROCtools GitHub repository. As for Numba ROC? Well, I’ve already spent so much time troubleshooting and debugging various issues (in general, not all of them are Numba-ROC-related) related to my old Vega 56 and my new RX 6800 that I really don’t want to deal with this issue any longer.

Fortunately I still have my old Vega 56 which I can swap out my RX 6800 with if I absolutely need to use Numba ROC, but especially as I already ran into other software issues swapping graphics cards on my PC, I think unfortunately I might just have to switch to something like PyOpenCL at this point and forget about using Numba ROC :confused:.

Might I ask a little about your interest in the ROC target? Are you looking to make use of your existing hardware to its full potential, or do you have a more general interest in GPU computing?

The reason I ask is that if you’re generally interested in GPU computing, it’s possible to get started with the CUDA target using free instances on some platforms, e.g. Google Colab: if you head over to https://colab.research.google.com/ and create a new notebook, then select “Runtime” and “Change Runtime Type” you can swap the “Hardware Accelerator” dropdown from “None” to “GPU” and then experiment with the CUDA target. You will usually get an NVIDIA K80 or T4 - for example when I tried this today with:

from numba import cuda
cuda.detect()

I got:

Found 1 CUDA devices
id 0            b'Tesla K80'                              [SUPPORTED]
                      compute capability: 3.7
                           pci device id: 4
                              pci bus id: 0
Summary:
	1/1 devices are supported

If this is interesting, you might also want to have a look at the Numba CUDA tutorial - also feel free to post any further questions to this Discourse or chat in the Numba Gitter, and I’ll do my best to help out.

@gmarkall

Thank you for your CUDA target recommendations using free instances on online platforms; I wasn’t even fully aware of such free online instances until you mentioned it in this thread. I am indeed interested in GPU computing in general, but I’d also very much like to use my existing hardware to its full potential especially as one of the reasons why I’d poured a lot of money into upgrading to a RX 6800 was to get substantially better GPU computing performance. With my budget at the time I could’ve gone with a RTX 3070 but unfortunately the VRAM capacity on a 3070 simply wasn’t enough for some of my use cases (e.g. profiling runtimes of algorithms using very large sets of data). Therefore, in the end I’ve decided to switch to PyOpenCL like I’ve said for my own GPU computing programming.

Thanks again for the recommendation and take care :slightly_smiling_face:.

1 Like