AMD's HSA Run-Time Library Is Now Open-Source

[CrystalGamma]

AMDKFD is about HSA -> scheduling and executing general computational tasks on GPU or CPU

AMDGPU is about kernel driver for AMD gpus 285 and onward

So you need AMDGPU if you own 285 and want to use Mesa (and Catalyst will use it soon too!), for 2D/3D/video/audio accelerated on GPU.
AMDKFD is about HSA. If you want to use HSA (there isn't much software right now, but soon some will come), you need this.... AND working GPU. This GPU may be 285 for example, and then You would need Catalyst or AMDGPU+Mesa, if you have 78xx then it would be radeon+Mesa.

Treat AMDKFD as kernel part of HSA.

Well yes, but what does that mean?
Is that what you call "HSA driver" lower or higher level than the GPU driver?
If it is higher level, then what service does it provide that the GPU driver does not?
If it is lower level (command submission), what is left for the kernel GPU driver to do?

[Adarion]

Aww, this is so great I decided to save some money for xmas for a Kaveri system. The problem is to find a mainboard that does have working chips on it. The superIO situation is still a dire one.

[log0]

Well yes, but what does that mean?
Is that what you call "HSA driver" lower or higher level than the GPU driver?
If it is higher level, then what service does it provide that the GPU driver does not?
If it is lower level (command submission), what is left for the kernel GPU driver to do?

http://lwn.net/Articles/605153/

"AMD GPUs designed for use with HSA (Sea Islands and up) share some hardware
functionality between HSA compute and regular gfx/compute (memory,
interrupts, registers), while other functionality has been added
specifically for HSA compute (hw scheduler for virtualized compute rings).
All shared hardware is owned by the radeon graphics driver, and an interface
between kfd and kgd allows the kfd to make use of those shared resources,
while HSA-specific functionality is managed directly by kfd by submitting
packets into an HSA-specific command queue (the "HIQ")."

[bridgman]

Excellent -- it's nice to see that someone actually reads that stuff

A bit more background -- both the runtime (released yesterday) and the kernel driver are meant to serve both as initial implementations for AMD hardware and as a starting point or reference for development efforts by other HSAF companies. We use additional hardware in our GPUs to implement the usermode queues*, but other HSAF partners are using DSPs or dedicated compute accelerators so the driver needs to be a bit more generic.

* one of the cool things about usermode queues is that they provide a common work-queueing interface for both CPU and GPU, ie code running on a GPU (HSA device) can queue work to itself or to other GPUs (HSA devices) without having to trap into the CPU

If you look at the runtime source, you'll see that a lot of it is vendor independent -- the idea is that most of the code can be shared across HSA implementations. The kernel driver is more vendor-specific at the lower levels (and it calls into the kernel graphics driver when touching shared GPU hardware or allocating shared resources eg memory, compute queues or VMIDs**) but we tried to keep the IOCTL interface vendor-independent.

** we use VMIDs to identify which process address space / page table set should be used for a particular operation, allowing work from multiple processes to be queued into the GPU at the same time while preventing the GPU from accessing data from another process

[tmpdir]

Ah, very nice. Can't wait to get home today to download this code and check it out. I think this is extremely cool.



My opinion is that you should wait for the next generation of cards that is said to come in Q1 2015, since they are said to have HSa support. My understanding is that currently only Kaveri APUs have HSA support. (But I could be wrong...)

As I said in my previous comment R9 285 chipsets and newer will use HSA.

p.s. the text you quoted from me seem largly from somebody else?

[tmpdir]

Thanks, I think I understand now what it is and it seems like it could be a pretty fair winner.

I'm looking at the newest AMD APU - the 12 core AMD A10-7850K Kaveri, it's just a little weird to think of using integrated graphics, but I guess it scored pretty fair on CPU Boss against my current CPU

@tmpdir - B - (r9 285 and up) What does this mean? Does it mean AMD Graphics cards outside the AMD A10 APU will benefit from this HSA driver?

I meant R9 285 chipsets and newer will benefit from this. I'm not up-to-date with IGP's but I think its an older architecture so that will probably not be supported.

[bridgman]

As I said in my previous comment R9 285 chipsets and newer will use HSA.

p.s. the text you quoted from me seem largly from somebody else?

HSA support starts with Kaveri. The quoted text came from the commit message at the lwn link that log0 provided (which I wrote and Oded added to the front of the patch series).

Is there any chance you are thinking of amdgpu (which will start with R9 285 as you say) rather than amdkfd (which starts with Kaveri) ?

[bridgman]

The quoted text came from the commit message at the lwn link that log0 provided (which I wrote and Oded added to the front of the patch series).

tmpdir please ignore this part, I misread your email and then the CENSORED 5 minute edit limit got me...

[nanonyme]

tmpdir please ignore this part, I misread your email and then the CENSORED 5 minute edit limit got me...

I don't know why but people quoting themselves always looks rather cute.

[phred14]

Please pardon the silly detail question. I'm finding and reading what I can and attempting to make practical sense of this. There appear to be three-to-five parts to HSA, and at the moment none of it is really mainstream. Probably no guess of mainstream availability can be made at this time, so I won't even ask. But if I want to jump the gun I can start patching on my own.

1 - AMDKFD driver - not yet in the kernel proper, but patch set is available.
2 - The HSA runtime - available as source, though probably not in any distributions yet.
3 - A new version of LLVM - presumably available as patches, not yet in the mainstream.

4 - Will this work with the stock radeon/radeonsi driver, or is there a set of patches for that, also?
5 - I presume this needs a new/patched OpenCL library that is designed to sit on top of HSA, or does the HSA runtime implement/replace OpenCL libs?

Just curious about what's needed to make this actually usable. I'm guessing it will be a good six months before it's all in the testing/~arch branch of any distribution.