AMD Releases Radeon ROCm 1.5

[difron]

And what about SPIRV frontend? Is it somewhere in TODO list?

[bridgman]

... and when you started rewriting your OpenCL stack you had already decided to go for an hybrid route, so why not developing the new OpenCL stack in the open since the beginning?

We didn't develop a new OpenCL stack, and we didn't rewrite the OpenCL driver as part of the amdgpu hybrid effort, other than changing the Linux GPU back-end to call into amdgpu rather than fglrx and doing the usual testing & optimizing work.

What we hve been doing as part of the current open sourcing effort is making incremental changes to the closed source OpenCL driver, replacing some of the components with new code generally based on already-in-the-open open source projects.

[darkbasic]

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

WHY? You are developing open drivers since a decade and when you started rewriting your OpenCL stack you had already decided to go for an hybrid route, so why not developing the new OpenCL stack in the open since the beginning?

[darkbasic]

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

I am *only* interested in opensourcing it, but most of peoples probably just want to be able to use their hardware. That's why the "most boring thing i read on Phoronix is continuous asking AMD to opensource something every another day". Unfortunately there are not so many people who believe in open source

[bridgman]

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?

The llvm changes are either already either in or going in AFAIK.

We are starting another up-streaming exercise for the latest kernel code now that eviction logic is implemented, Vega10 is merged and the ROC kernel code has been re-synced with latest open & hybrid gfx driver code. Next step will probably be moving everything onto 4.11 but we can start some RFC-level review in parallel.

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

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

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

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

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.