AMD Releases Radeon ROCm 1.5

[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

[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.

[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]

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... :-)

[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.

[dungeon]

It's simply full of peoples wanting to use their hardware. By the way their binaries are almost impossible to use unless you use distribution X at version Y where Y << Z (current version).

So you are actually not interested in opensourcing it? I guess you will be fine with all blobs if it swim on Gentoo well

[juno]

Will ROCm eventually be usable with an upstream Kernel?
If it's true what bridgman said (all components are free software), there is no reason to not push everything in amdkfd upstream?


edit:

It is fully open source other than OpenCL AFAIK, and we are continuing to work on opening up OpenCL.

Is there something else closed-source which I missed ?

Maybe he was referring to that:

Closed source components

The ROCm platform relies on a few closed source components to provide legacy functionality like HSAIL finalization and debugging/profiling support. These components are only available through the ROCm repositories, and will either be deprecated or become open source components in the future. These components are made available in the following packages:

• hsa-ext-rocr-dev

[darkbasic]

Most boring thing i read on Phoronix is continuous asking AMD to opensource something every another day

It's simply full of peoples wanting to use their hardware. By the way their binaries are almost impossible to use unless you use distribution X at version Y where Y << Z (current version).

[dungeon]

Most boring thing i read on Phoronix is continuous asking AMD to opensource something every another day

[darkbasic]

It is fully open source other than OpenCL AFAIK

Which unfortunately is one of the most important pieces for the end user. Any ETA for OpenCL?