Setting Up The Radeon Open Compute Platform On Linux

[bridgman]

I think it's actually quite confusing with the naming again... so the "new ROCK kernel driver" isn't actually a new kernel driver but instead just features additions to amdgpu/amdkfd that might not go upstream?! So the OpenCL driver will still hook into amdgpu via libdrm_amdgpu, and not require a new kernel driver?

ROCK is the latest internal version of amdgpu/amdkfd, with additions that can't go upstream in their current form. We have been working on upstreamable code in parallel. In the short term OpenCL will continue to hook into amdgpu via libdrm_amdgpu and not require a new kernel driver, however we are probably going to move OpenCL over the ROC stack once it has been integrated (via upstream) into the all-open and hybrid drivers.

[bridgman]

A while back I purchased a Kaveri desktop, hoping someday to do some simulation development with it, and knowing that it would be at least a year until HSA support matured sufficiently for a non-expert (like me) to use. That said, I mostly quit paying attention to it all, just occasionally seeing that bits and pieces appeared to be progressing. With this announcement there appears to be a new range of alphabet soup, and I get a distinct flavor that my Kaveri has been left in the dust - that the maturing software will be maturing for new products.

Can you comment / set me straight / reassure? I hope to become interested in electrical / physics simulation with this machine. (This was purchased as a potential "retirement computer", and that stuff will interest me more then.)

One of the questions we are discussing now is whether we should stay with the "pure HSA" programming model for Kaveri in the short term or focus on the ROC subset/superset (it's both) that we are supporting on dGPU. The two models should converge over time but in the short term I'm leaning towards treating the Kaveri GPU like a least-common-denominator dGPU system so that any code written for or ported to the ROC stack has a good chance of "just working" on Kaveri as well.

BTW the primary difference between the programming models is that the current Kaveri/HSA stack allows GPU access to unpinned OS-allocated memory, while the ROC stack on a dGPU requires that GPU-accessed memory be allocated & pinned via API calls.

Anyways, the short version is that we haven't forgotten about Kaveri but making sure the market doesn't forget about it when supporting big-ass dGPUs might require us to tweak the Kaveri/Carrizo stack a bit (to match what a dGPU can do), and that's one of the things we are discussing now.

[jstefanop]

The OpenCL driver we release in open source will probably run over ROC.

Think about ROC as part of the normal driver stack, just developed on a separate schedule from graphics driver releases and initially targetting new business areas. The code is being integrated via upstream and ROC will become just another part of the open and hybrid stacks.

So as of today, what is the best driver stack to run openCL compute applications using tonga based cards on linux?

We are currently running a headless 8 GPU system on 14.04 server with fglrx_core for the "minimal" setup. I know 16.04 will utilize AMDGPU and tonga is supported by it...but not sure how well openCL is implimented in its current state.
14.04 and fglrx_core worked great for tahiti based cards, but its rather flakey with tonga. Since I dont see any more updates happening with fglrx, I was hopeing there is a driver stack that has more active dev on it that we can test.

[bridgman]

I would start moving towards amdgpu hybrid immediately, at least for testing (maybe on a spare hard drive). It uses the same OpenCL runtime and compiler as Catalyst/fglrx, although the kernel driver & interface library are new.

We are just starting the QA cycle on the next release so now would be a great time to find & report bugs.

[jstefanop]

I would start moving towards amdgpu hybrid immediately, at least for testing (maybe on a spare hard drive). It uses the same OpenCL runtime and compiler as Catalyst/fglrx, although the kernel driver & interface library are new.

We are just starting the QA cycle on the next release so now would be a great time to find & report bugs.

Sorry for all the spam posts...forum was acting weird earlier...i just deleted all the duplicate posts.

Anyway so does AMDGPU hybrid offer something similar to the fglrx_core package...so only things needed for compute are loaded and no 3d stuff?

[bridgman]

Should be even more adaptive than fglrx - if you don't have a display attached then it doesn't even allocate a frame buffer. At least that's how it was a few months ago, haven't tried it recently.

[jstefanop]

Should be even more adaptive than fglrx - if you don't have a display attached then it doesn't even allocate a frame buffer. At least that's how it was a few months ago, haven't tried it recently.

Id still rather install only the basic packages needed for just compute. Its installing x server stuff as well.