I am super excited about this driver. I worked on the early drm first at Precision Insight and then at VA Linux Systems, and having hardware validated command streams seperate for each process is just such a huge deal for performance. I wrote some proof of concept code awhile back that I posted to the Mesa dev list for doing something like this without hardware support, and based on my limited testing it would be a huge improvement in dma throughput. Its nice to see something like this happening finally, I think it is a path to getting a secure and highly performant driver. We have always had to make security tradeoffs with performance in Linux land, now we actually might have the infrastructure to get a chance at matching or beating Windows performance. Terribly exciting.
I glad to hear that, for a long time I've always considered Windows HAL (certainly XP/2000 and beyond) to be something the Linux kernel needed to really tackle the desktop.
Heterogeneous System Architecture (HSA) driver
for radeon-family GPUs.
HSA allows different processor types (CPUs, DSPs, GPUs, etc..) to share system resources more effectively via HW features including shared pageable memory, userspace-accessible work queues, and platform-level atomics. In
addition to the memory protection mechanisms in GPUVM and IOMMUv2, the Sea Islands family of GPUs also performs HW-level validation of commands passed in through the queues (aka rings).
The exciting part of HSA though is the APU architecture that AMD is putting out. Its hardware specific, but the CPU and embedded GPU have a coherent cache. (CPU and GPU are on the same die with APUs).
Agreed, that's the most thrilling development to HSA in my eyes. Coherent memory structures (with much of it shared) all the way down truly elevates the GPU to first-class citizenship.
What I don't really see, HSA-wise, is how they plan to cater for the fact that graphics and compute cores favour significantly different types of memory (DDR vs GDDR). From what I understand, one of the major cripplers of on-die graphics so far as been its reliance on the same bog-standard memory interface shared with the CPU. How will this interact with AMD's side-port memory schemes?
1. From the security point of view, does HSA driver present a significant additional attack surface? I imagine some new kinds of tricks could become possible, like they did with Hyper-Threading http://www.daemonology.net/hyperthreading-considered-harmful...
2. Is HSA driver a roadblock for virtualization of the OS?
Has AMD HSA development been purely a Windows (and game console?) affair up until this point?
edit: now I see that they've had a github up with Linux HSA drivers for a while now. Is the significance of today's thing that the patches are making it into the mainline kernel?
HSA's requirements are far broader than those provided in Metal. A7's shared memory implementation appears to be far too basic to be able to implement HSA-type API. For example, on-demand paging, user-mode queueing and ability for GPU to do CPU callbacks. Many systems can have shared memory but are not HSA compliant.
Samsung and TI don't design their own GPUs so it'd be surprising to see them outpacing AMD in this. Qualcomm's efforts also appear to be behind AMD so far, and they don't appear to have as much priority for it as AMD does.
