Slashdot Mirror
AMD Goes Open Source, Announces GPUOpen Initiative, Linux Compiler, Drivers (hothardware.com)
MojoKid writes: AMD announced today that the company is releasing a slew of open-source software and tools to give game developers, heterogeneous applications, and HPC applications deeper access to the GPU and GPU resources. AMD and their Radeon Technologies Group (RTG) are looking for ways to ease game development, so developers can more easily re-use code and port their games from consoles over to the PC. With GPUOpen, game developers will have direct access to GPU hardware, as well as access to a large collection of open source effects, tools, libraries and SDKs, which are being made available on GitHub under an MIT open-source license. As part of the effort, the company is also releasing a new HCC C++ compiler which will be a tool in enabling developers to more easily leverage the resources of discrete GPU hardware in heterogeneous systems. The HCC complier also allows developers to convert CUDA code to portable C++. According to AMD, internal testing shows that in many cases 90 percent or more of CUDA code can be automatically converted into C++ with the final 10 percent converted manually in the widely popular C++ language. An early access program for the "Boltzmann Initiative" tools is planned for Q1 2016.
Decent Windows/Linux drivers now?
Religion: The greatest weapon of mass destruction of all time
Certainly makes AMD to look a bit more ethical in my eyes now.
Coming next is Windows Server for GPU an will be licensed by GPU core.
i.e. similar to how Netscape went open source right before "Netscape" the commercial company went away (bought by aol... then becomes mozilla which outputs current firefox).
AMD seems desperate to garner any headlines it can these days. How much open source gaming is really around, and how many will think this is going to sway any gaming developer over to AMD solely? I get that many games for PC's are designed for certain hardware, but that's always been the case and it has never really amounted to any significant dedication from users for certain hardware. I keep reading how great Linux games are, but its nothing compared to the rest of the retail gaming ecosystem and never will be. Good luck AMD catering to a very small group as if this will save yourselves from complete collapse. It won't.
I see lots of articles about how AMD plans to do this, that, and the other using open source components. What I want to know, is can I run 3D games using the in-tree kernel module with the proprietary user modules yet? This was promised a while back and I haven't seen any more about it. I want to support the effort, but I am not buying another AMD card until I see it actually work.
I think the appropriate response is "I'll believe it when I see it". AMD has cried wolf WAY too many times on this matter. I can remember getting excited about AMD "open sourcing" their stuff 10 years ago, but it turned out to be little more than a Microsoft "open sourcing", i.e. half-assed with strings attached.
while i think this is great, i'll wait for AMD's GPU driver to actually show up in the kernel upstream before putting any stock in what they say.
Anons need not reply. Questions end with a question mark.
then having a MIT license might give them a edge of nvidia. Or not.
Don't AMD announce some new open source initiative every year?
Nothing ever happens.....
Then please inform me, wise coward, what this "radeon" driver is, that has satisfied my needs for years?
When all you have is a hammer, every problem starts to look like a thumb.
is this the last gasp for amd?
i.e. similar to how Netscape went open source right before "Netscape" the commercial company went away (bought by aol... then becomes mozilla which outputs current firefox).
Probably not, but it is an act of desperation. It's no secret that in the past AMD and nVidia has been very anxious to keep Intel out of the high performance graphics market. That gap is closing fast, even though they don't do discrete cards they're quite efficient and well-supported with almost 20% market share on Steam. Meanwhile nVidia has been very successful pushing their GameWorks middleware, G-Sync, CUDA and other proprietary nVidia-only technologies. So I think this is AMD realizing they can't win a war on two fronts and trying to make common cause with Intel to share AMD's middleware to get game support, while still hopefully being able to find a niche for their hardware.
Of course the risk is that Intel just gobbles up AMD's graphics market share the same way Intel's almost completely gobbled up the x86_64 market but the way the gaming market is heading right now I don't think they have a choice. If letting Intel use their middleware can lead to better game support (probably) and Intel stays out of discrete cards (probably) and AMD can come up with discrete GPUs that match nVidia (maybe...) it might work. At least if this flops some good technology got open sourced, I don't like the implication that open sourcing is a last ditch attempt though. Intel is working hard on open source drivers in Mesa and that's hardly a failure.
Live today, because you never know what tomorrow brings
>> Then please inform me, wise coward, what this "radeon" driver is
A free driver wrapper around a nonfree firmware blob. To use it, you first have to install firmware-linux-nonfree. See https://wiki.debian.org/AtiHow...
The firmware blobs are released under a nonfree license. I am not saying this is bad or good, just observing that it is. Though I guess it does sound horrible now that you mention it--and I wish there were a reasonable solution.
Sorry, realized I hadn't been logging in or identifying myself as an AMD-er. So now I have an account. It's funny, for such a technical site the account setup questions list a lot of management positions but nothing for the technical side. AFAIK most tech companies these days have parallel management and technical tracks, don't they ?
>>Hope you understand what Im trying to say. Im sure I sound like a negative and pessimistic jerk but Im really not. Nope, I understand completely and you said it very well (better than I was doing). The problem is arguably as simple as "guilt by association"... ie in order to let the drivers load microcode that is distributed in hardware or flash on competing products you need to use an OS mechanism which also allows the use of other, obviously more problematic "firmware" blobs which clearly do perform functions that would otherwise be implemented in the driver. I don't know if there is a solution in there but if nothing else it might help to explain to board vendors why people care about not having to ship the microcode images as part of the "software". Thanks.
(removing quote for clarity) Nope, I understand completely and you said it very well (better than I was doing). The problem is arguably as simple as "guilt by association"... ie in order to let the drivers load microcode that is distributed in hardware or flash on competing products you need to use an OS mechanism which also allows the use of other, obviously more problematic "firmware" blobs which clearly do perform functions that would otherwise be implemented in the driver. I don't know if there is a solution in there but if nothing else it might help to explain to board vendors why people care about not having to ship the microcode images as part of the "software". Thanks.
I would perhaps consider the border of when its OK and not OK to be if you can change the code or not. That is also the reason Im not sure about the VBIOS part.
I don't want you to the get wrong picture. Its great that the microcode can get updated. But its more of an ethical question.
Yep, the ability to update the microcode is often used as a criteria for whether something is "software" or not, but following that line of thought quickly leads to what I think everyone agrees are counter-productive conclusions. For example:
1. Burning microcode into the chip is OK, and we promote use of those chips when accompanied with free drivers even if the microcode is not free
2. Making the microcode upgradable (which helps us) is even better, but we explicitly prohibit use of those chips unless the microcode is also free, even if the drivers are completely free except for loading the microcode
3. Even though microcode changes are normally made only during pre-launch development or in order to SUPPORT the development of free drivers we penalize users of that hardware because the microcode COULD be changed
4. Even if we put controls in the driver code to prevent changes to the microcode (eg validating a hash) so that the microcode can never change we still penalize users of that hardware, even though we think changeable microcode is otherwise better
5. If the microcode were distributed in the VBIOS ROM the libre OS builds would allow full, accelerated use of that hardware because the drivers could then be considered totally free, despite the microcode still being changeable and the drivers being otherwise identical, but we don't want to make exceptions for that exact same microcode/driver combination in the distros themselves
(in fairness the decision to lump all microcode and firmware into a single repo was made upstream in Debian not downstream in the libre OSes)
http://people.freedesktop.org/~agd5f/radeon_ucode/tonga/
AFAIK the microcode images can be downloaded directly from Alex's radeon_ucode folder on freedesktop.org (folder above is for 285/380/380X), but once folks come back from vacations I'll ask about packages that can take care of the install details.