AMD Releases Radeon ROCm 1.5

[bridgman]

Why does it take so long to open up OpenCL? I'm not holding hot pokers here but this step really is taking longer than I hoped so I'm hoping you can inform us as to why.

I would argue that the real question is "why would you expect it to be quick ?". Opening up a written-for-closed-source component typically involves re-writing / replacing big chunks of the code, and that was certainly the case for OpenCL:

- replaced proprietary EDG compiler front end (parser) with clang
- replaced AMDIL-based proprietary compiler back end (sc) with LLVM-based shader compiler (aka "Lightning compiler")
- replaced fglrx-era device code with ROCm back-end

In addition to the above, the code base also included Vega10 support so the usual embargo requirements apply as well.

Also, what's the status on axing the closed source hsail component? My google-fu wasn't strong enough to find the current situation and I'm not really sure where to find a "changelog" other than looking through the distributed commit histories... which I also tried and always ends as a time sink.

Already axed AFAIK. The ROCm paths are using an open source direct-to-ISA path now, sharing LLVM back-end code with the open source graphics drivers. I saw juno's comment re: README references to HSAIL & debug - I suspect those references are just left over from earlier ROCm release notes but will check.

EDIT - initial feedback is that some of the older sample programs still use HSAIL and so the closed source bits are required for those older samples only. Still waiting to hear back from a couple of other people and about debug.

[nevion]

I would argue that the real question is "why would you expect it to be quick ?". Opening up a written-for-closed-source component typically involves re-writing / replacing big chunks of the code, and that was certainly the case for OpenCL:

- replaced proprietary EDG compiler front end (parser) with clang
- replaced AMDIL-based proprietary compiler back end (sc) with LLVM-based shader compiler (aka "Lightning compiler")
- replaced fglrx-era device code with ROCm back-end

I never expected it to be quick, I've tracked this and several items I've cared about since ROCm went public. My expectations are always kept in line with the developers comments for each release or issue I don't intend to hold anyone over hot coals for missing a target, but I do want to refresh my understanding of state and estimate the next potential date the feature arrives as well as gain insight the cause of the delay based on your explanations (this helps to make realistic projections). Perhaps I erred and crossed goals with milestones they didn't belong to - with the pace and difficulty of keeping track, it's very possible I mixed something up. It's a fact that OpenCL developers have had patience beaten into them though.

I recall something being the queue regarding submitting your OpenCL implementation to Khronos for validation or conformance tests IIRC. How's that going?

In addition to the above, the code base also included Vega10 support so the usual embargo requirements apply as well.

Oh... :-)

[coder]

I don't intend to hold anyone over hot coals for missing a target, but I do want to refresh my understanding of state and estimate the next potential date the feature arrives as well as gain insight the cause of the delay based on your explanations (this helps to make realistic projections).

Um, and you're paying how much for this, exactly?

It's one thing, if AMD makes public commitments and misses them, to inquire about an update to their plans. But you sound awfully demanding for someone who's probably just an individual customer of their hardware.

As for myself, I only care about good distro support (to darkbasic's point) and that it works well. With those two conditions met, you can get a lot of software projects using their stack.

[nevion]

Um, and you're paying how much for this, exactly?

More than you think, but less than I'd hoped to so far.

It's one thing, if AMD makes public commitments and misses them, to inquire about an update to their plans. But you sound awfully demanding for someone who's probably just an individual customer of their hardware.

Demanding eh - more like opportunistic and watching like a hawk. Ask a question and see if it gets answered is my mentality. I'm a concerned citizen and developer (as in my livelihood is tied to this) and have been for a long time. These timelines/scales also matter as to when I propose a project uses AMD hardware, I have to be realistic that hardware & software will work the way it's needed to and unfortunately it's not always possible to control timing of acquisition or when I'll have to make such recommendations - so I need to always have an idea of the state of things and where it's going.

[boxie]

I would argue that the real question is "why would you expect it to be quick ?". Opening up a written-for-closed-source component typically involves re-writing / replacing big chunks of the code, and that was certainly the case for OpenCL:

- replaced proprietary EDG compiler front end (parser) with clang
- replaced AMDIL-based proprietary compiler back end (sc) with LLVM-based shader compiler (aka "Lightning compiler")
- replaced fglrx-era device code with ROCm back-end

In addition to the above, the code base also included Vega10 support so the usual embargo requirements apply as well.



Already axed AFAIK. The ROCm paths are using an open source direct-to-ISA path now, sharing LLVM back-end code with the open source graphics drivers. I saw juno's comment re: README references to HSAIL & debug - I suspect those references are just left over from earlier ROCm release notes but will check.

EDIT - initial feedback is that some of the older sample programs still use HSAIL and so the closed source bits are required for those older samples only. Still waiting to hear back from a couple of other people and about debug.

Thanks for the extra info bridgman - as always you are awesome

[bridgman]

EDIT - initial feedback is that some of the older sample programs still use HSAIL and so the closed source bits are required for those older samples only. Still waiting to hear back from a couple of other people and about debug.

One more update...

I'm told that nearly all of the sample programs have been replaced/rewritten to use non-HSAIL kernel code, and that we are down to one last sample program - vector copy - which requires the closed source bits. Not sure about debug yet.

I never expected it to be quick, I've tracked this and several items I've cared about since ROCm went public. My expectations are always kept in line with the developers comments for each release or issue I don't intend to hold anyone over hot coals for missing a target, but I do want to refresh my understanding of state and estimate the next potential date the feature arrives as well as gain insight the cause of the delay based on your explanations (this helps to make realistic projections). Perhaps I erred and crossed goals with milestones they didn't belong to - with the pace and difficulty of keeping track, it's very possible I mixed something up. It's a fact that OpenCL developers have had patience beaten into them though.

I think the last thing we said on this was that the 1.4 release would definitely not have open source OpenCL, so it's fair to be asking about open source in the 1.5 timeframe. We wouldn't hold up the rest of the ROCM release waiting to open source OpenCL though.

I recall something being the queue regarding submitting your OpenCL implementation to Khronos for validation or conformance tests IIRC. How's that going?

I wouldn't expect Khronos submission to be on the critical path for an open source release... that said I'm not sure about conformance status for OpenCL over ROCm, will try to find out.

[funfunctor]

nevion it seems bridgman and friends came though on this one after all although I agree if the process was less opaque it would have been better for the customer but any way, thanks bridgman!

There is compute stuff heading into the next two merge windows of the kernel and the llvm changes have been making their way into upstream. The kernel changes have taking longer than I would have expected however that seems to be getting fixed now that compute hardware is coming out specifically now. I expect the whole thing will be properly working for ye'old average joe probably around 4.15.

bridgman how will the OpenCL loader pick up this new wizbang thing and how will that be distributed? As you probably guessed I didn't look into the CL side of compute yet, only HSA at the lower level.

[bridgman]

bridgman how will the OpenCL loader pick up this new wizbang thing and how will that be distributed? As you probably guessed I didn't look into the CL side of compute yet, only HSA at the lower level.

The OpenCL runtime used to have three different back ends - CPU, Windows gfx kernel driver and Linux gfx kernel driver. We added a fourth back end for ROCm (going through ROC runtime and thunk/KFD) and switch between GPU back ends based on device ID and OS.

The new OpenCL involves both new runtime and new compiler (we're using the same compiler back end for OpenCL over ROCM as for HCC AFAIK). I'm a bit fuzzy on how the front ends fit together but have that on my things-to-understand list.

I *think* the model is 3 front ends (HCC, OpenCL clang and graphics TGSI-to-LLVM IR) and one back end (LLVM IR to GCN ISA) but not sure enough to say that with confidence yet.

[juno]

bridgman can you say something about upstreaming plans? Will the changes likely land in upstream kernel and llvm? Is that even something you are trying to achieve or is the ROCm meant to stand on it's own?

[Marc Driftmeyer]

So sometime in 2018 for OpenCL to work correctly in FOSS? Sorry, but it better be OpenCL 2.1 or it's pathetic. 1.2 was announced nearly 5 years ago.