Having mesa-libOpenCL installed prevents ROCm's OpenCL from functioning; I previously assumed it was a result of the ROCm issues we've had before, but I now re-tested it by removing mesa-libOpenCL to ensure a clean test of ROCm. With this re-test, it seems like ROCm does work so long as mesa-libOpenCL isn't installed. Intel w/ intel-compute-runtime is unaffected either way. From re-investigating previous issues, it turns out that any issue reports related to ROCm not working, of which there weren't many, were either brief mentions of it by myself, or were reported after the original addition of mesa-libOpenCL. In other words, ROCm being completely "broken" for the past year has most likely been because I added mesa-libOpenCL to test rusticl in the first place, and I never thought to try removing it to re-test ROCm until now.

Incidentally, the issue with OpenCL-ICD-Loader vs ocl-icd (#169) only affects mesa-libOpenCL. Both intel-compute-runtime and ROCm work perfectly fine with either package; it's only mesa-libOpenCL that has issues with OpenCL-ICD-Loader and needs ocl-icd.

As it stands now, I'm strongly considering reverting to ROCm as the default as it is more performant than rusticl, with instructions provided for using rusticl manually. The biggest concern here is for users of older AMD cards (i.e. Polaris and prior) where ROCm may still not work and rusticl would be needed.

Ideally, I'd like to keep rusticl as a fallback and have the two coexist, but it seems that this will require more work, or may just not be possible.