Gallium3D's LLVMpipe Lands NIR Support Plus Radeon R600g NIR Support Is Forthcoming

[MadeUpName]

Yes, that is correct. It is what keeps Darktable from having openCL support with AMD when using Mesa. AMDs packages for ROCM still don't support RH8 and I suspect will never support Fedora. I will eat a gun before I will use Ubuntu, how that became AMDs reference platform is a serious mystery.

[bridgman]

AMDs packages for ROCM still don't support RH8 and I suspect will never support Fedora. I will eat a gun before I will use Ubuntu, how that became AMDs reference platform is a serious mystery.

The kernel code is maintained upstream should already be in standard Fedora distributions. We structure the ROCm packages so that you can install userspace on top of built-in kernel code for that reason.

I haven't tried installing the RHEL userspace packages on latest Fedora myself (vacation is coming so will try then) but my impression was that it should pretty much work, with most of the problems seeming to come from other OpenCL packages that were still there and getting in the way.

There is background work going on to improve the Fedora situation, including scripts to install ROCm on Fedora, but we need to do more general cleanup of the build environment before we can get to the point where it's packaged with Fedora. The scripts aren't being regularly updated yet - my impression is that they tend to move forward when developers are on vacation and can work on their own priorities:

https://github.com/RadeonOpenCompute/Experimental_ROC

Ubuntu LTS ended up as our reference platform simply because it was what most of our OEM and embedded customers were requesting. That is more for graphics than compute but it's pretty much the same driver stack and same developers.

The developers tend to move back and forth between Ubuntu and Fedora depending on which distro last did something annoying to them.

Most of our focus has been on enterprise distros, primarily RHEL/CentOS although as new customers come on stream we are getting demand for SLES and Debian as well.

[bridgman]

Yes it does. (Though presumably he was probably meaning for Mesa OpenCL as opposed to 'proprietary' drivers. Just like Intel's OpenCL NEO has images + CL 2.0/2.1, etc)

It's a sad day when open source out of tree drivers get described as "proprietary" just because they are not upstream

[xen0n]

Typo:

The NIR support is currently wired up in LLVMpioe

[log0]

I've recently replaced my good old HD4850 with a R7 from ebay for 25€ (a steal). It was probably the longest-lasting GPU I've ever owned. RIP.

[MadeUpName]

It's a sad day when open source out of tree drivers get described as "proprietary" just because they are not upstream

I take your point. But your kind of stretching that beyond what I actually mean. A lot of people my self included can only get work done by using AMDGPU-Pro because there is currently no functioning alternative. ROCM stopped working for every one running DR after ROCM 1.2 and people that can't stick with RH7 can't use it. My graphics card shouldn't be deciding which OS and which software I will use.

ROCM very much is up stream what is missing is down stream. What I remember from about 6-9 months ago was some one posting that the code for thunk wasn't fit for purpose because of all of the links in it pointing to the wrong places. Going through and changing those every time AMD patched would be too painful for a packager and a solution needed to be found. Who ever posted that proposed helping the AMD coders understand how the GNU tool set could help with that and offered to help. To the best of my knowledge that wasn't followed up on. ROCM may be open source but it certainly isn't an open source project. If people started submitting patches to modify it to work with the GNU tool set would AMD accept those patches? If not then whiie there may be an upstream implementation it may never be usable again by any one not running Ubuntu. So if you use some thing other than Ubuntu does a ROCM driver actually exist?

Don't get me wrong I like AMD and have stuck with them for both my CPU and graphics needs even when they flat out sucked next to the competition. I am happy to see them with some strut in their step again after all these years. But OpenCL is a real thing now and if you want to get work done you need it. Having to reinstall the OS every time I patch because I am stuck with AMDGPU isn't a functional solution. If NVidia gives me what I need and AMD doesn't then I am going to have to switch. I hate NVidia and yes their drivers are proprietary. But they also work with every thing I need and give me functionality I can't get from AMD. I wish that wasn't the case.

[bridgman]

I take your point. But your kind of stretching that beyond what I actually mean.

No question about that... I was responding to Michael's paraphrasing of your comment and joking a bit about the dual use of "proprietary" we see today - vendor-specific vs closed-source.

ROCM stopped working for every one running DR after ROCM 1.2 and people that can't stick with RH7 can't use it. My graphics card shouldn't be deciding which OS and which software I will use.

Sorry, what is DR ? I might be a bit slow today. I'm sure it will come to me after I post this.

ROCM very much is up stream what is missing is down stream. What I remember from about 6-9 months ago was some one posting that the code for thunk wasn't fit for purpose because of all of the links in it pointing to the wrong places. Going through and changing those every time AMD patched would be too painful for a packager and a solution needed to be found. Who ever posted that proposed helping the AMD coders understand how the GNU tool set could help with that and offered to help. To the best of my knowledge that wasn't followed up on.

ROCM may be open source but it certainly isn't an open source project. If people started submitting patches to modify it to work with the GNU tool set would AMD accept those patches? If not then whiie there may be an upstream implementation it may never be usable again by any one not running Ubuntu. So if you use some thing other than Ubuntu does a ROCM driver actually exist?

I don't think there is any desire to be Ubuntu-specific, quite the opposite in fact. AFAIK the main challenge with reworking the build environment is trading off "doing it quickly" and "not breaking the internal CI systems we rely on today". It's an unusually busy time internally right now with new chips and new customers ramping up, and so we haven't been able to move as quickly on domesticating the build system as we would like.

One last thing - my understanding is that you don't actually need to build everything from source to get it running on Fedora... the existing packages have at least worked in the past (don't know if anyone has tested recently). I'll be setting up a new system over the holidays so will try to get it running with Fedora and ROCm stack. Worst case it will make me as unhappy as you

[smitty3268]

Sorry, what is DR ? I might be a bit slow today. I'm sure it will come to me after I post this.

Probably DaVinci Resolve?

[MadeUpName]

Thanks for the response bridgman. I'm sorry if I come off a bit testy but I used to think we were slowly making progress. All of the changes happening on the openCL front have me kind of worried. With NVidia yesterday you did Cuda, today you do Cuda, tomorrow you will do Cuda. It seems every time I log on here some one has come up with a new plan to scrap some part of the efforts for getting openCL working and start over or scrap openCL alltogether in favour of some thing else. That can't all be laid at AMDs feet, but it will scare off vendors and makes it very hard to follow how it is supposed to work today as opposed to how it worked yesterday.

Yes DR is Davinci. First I would never ask some one to burn their holiday time working on a tech project. I got out of tech because it consumed my entire life. I would never wish that on some one else. Enjoy what you can of your holidays. Second getting ROCM working with Fedora would be really great as I would be able to end having to reboot into RH in order to do a lot of work. But having said that I have no issue with you focusing on getting the RH8 stuff up to speed if that is AMDs priority as that is at least a workable if inconvenient solution. Porting from RH7 to RH8 would seem to be easier than the jump to Fedora. BTW the issue with using RH7 packages on RH8 or Fedora is that newer versions of RPM don't work with earlier versions of packages due to changing compression algorithms, check sums etc. I do appreciate your contributions bridgman.

Cheers

[FireBurn]

I still can't use an open source ROCM with either my M395X card or the Raven APU I have, I'm hoping to one day run some OpenCL test apps on an open stack before they're obsolete