AMD To Open-Source Its Linux Execution & Compilation Stack
Phoronix: AMD To Open-Source Its Linux Execution & Compilation Stack
In the discussion last night about AMD not having any plans to suspend their proprietary Linux driver, John Bridgman of AMD shared some interesting information about AMD planning to provide a full execution stack in open-source form...
Thanks Michael for reacting so quickly!
So it really seems not many people in the open source scene have recognized this?
Originally Posted by uid313
I don't really understand what this HSA is, and what its good for, and what it does, and why I should care.
It's abou fully integrating the computing capabilities of the GPU into the CPU, including preemption, cache coherency etc. Plus standardization, so it can be handled by different CPU (even GPU?) manufacturers and designers through a common API and toolset. Even if they use different (CPU) instruction sets like ARM vs. AMD. Binary code will still be different on different platforms of course. At least that's how I, as a non-programmer, understand it.
Does this mean that the flgrx is in the future half open source? And only need an Closed Source Userspace?
As far as the graphics driver is involved, my guess is more like it will be based on radeon (drm part) and Gallium. Or something new. But surely not fglrx. This also means that APUs including their graphics part will have to be supported in open source drivers from the day of release. Otherwise the server APUs that have already been announced for 2013 won't make sense. Still, that's not so hard because the APUs' gfx are one year behind discrete gfx cards and still will be in 2013. Different question here is HSA support for discrete cards of course.
Why C++ parser front-end will be proprietary? Couldn't they have used `clang`?
They probably used what is considered in the industry as the best C++ front-end: Edison Design Group C++. It's used by almost all larger companies that produce their own compilers (TI, Intel to name a few).
Looking at slide 29 of the HSA presentation, it looks like the Khronos APIs ( OpenGL, EGL, OpenVG, OpenGL ES, OpenCL etc.) will be implemented in terms of HSA. If that's true, I would take that to mean that a programmer might also be able to program directly with the HSA "language" as well... Or will it be a nice protocol similar to OpenGL et al. The mind runs wild.
As a person who enjoys programming more with memory-managed languages ( Common Lisp!), slide 26 is also very intriguing. I hope some other-than-Java languages can get some HSA love too. Especially, I hope that other languages aren't forced to try to make bindings for a C++ lib.
This is great news! I can't wait to see what comes of this. I was just telling my brother that "fixed-function" hardware is slowly loosing ground to programmable architectures like OpenCL even in the gaming world (with modern AAA game engines using voxel based lighting for real-time radiosity, etc), and that eventually we'll need a more common Open Source API to interface with than what OpenGL/DirectX HLSL/GLSL pipes provide. It looks like AMD has been thinking along this same line, and I'm excited to see what the future holds for AMD and Linux.
I was a bit disappointed with the latest AMD news about dropping Catalyst driver support for my 4870 before 12.4 worked with XOrg 1.12 (and beyond), I was planning on switching over to nVidia with my next computer, but I think AMD's just won back my support for a good long while ;-D