Slashdot Mirror
AMD Is Open-Sourcing Their Official Vulkan Linux Driver (phoronix.com)
An anonymous reader writes: While many of you have likely heard of the "RADV" open-source Vulkan driver, it's been a community-written driver up to this point in the absence of AMD's official, cross-platform Vulkan driver being open-source. That's now changed with AMD now open-sourcing their official Vulkan driver. The code drop is imminent and they are encouraging the use of it for quick support of new AMD hardware, access to the Radeon GPU Profiler, easy integration of AMD Vulkan extensions, and enabling third-party extensions. For now at least it does provide better Vulkan performance than RADV but the RADV developers have indicated they plan to continue development of their Mesa-based Vulkan driver.
Maybe AMD has understood that if you have the geeks on your side, than the next generation of general consumers will be yours as well. Because nobody, except the geeks, can tell two brands of hardware apart but everybody ask their geek family member for advice
this post contain no useful information, no need to mod it down
Nvidia and firmware makers tell us it's impossible because of 3rd party, security, competitive edge and a whole bunch of what now looks like excuses. I would love to hear from all the nay sayers how it was made possible ;)
well done, I hope system makers start making intel CPU with AMD GPU (sorry not meant as a back hand compliment)
Because AMD via AGESA has locked up all that same firmware on both the CPU/Motherboard and GPU platforms as closed source opaque and proprietary modules, same as everyone else.
What Intel and AMD have done (and Nvidia may have to do in the future in order to survive) is foist the many eyes/bugfixing part for the more resource intensive part of the driver architecture on the open source community, while maintaining control over the aspects which most endanger the end-user, while providing security to the content industry, and backdoors to the intelligence industry.
Unless we can get new players into both the cpu/motherboard platform ecosystem, and the GPU/Compute ecosystem, we are going to find ourselves with less and less control of own devices, and a harder and harder time of keeping 'secure-ish' hardware performant enough to retain access to modern applications and tools which leverage or require newer devices/memory capacities.
Until SATA/hard disks get fully replaced we at least have access to higher capacity long term storage, but basically every other peripheral is rapidly leaving pre-ME/PSP/Trustzone hardware in the dust.
I know the brand of GPU I'll buy for XMas.
Now that I got an alienware 13R3 you release the ryzen and this.... bollocks!
They've invested _a lot_ in open source graphics stack, release the specs (even they still have proprietary FGLXR driver)
I might even add :
their opensource driver is now currently considered the "official recommended one", while AMDGPU-PRO (the current closed source one, basically the successor of FGLXR, but with bits rewritten from scratch for better code sharing with the opensource drivers - it's mostly only a blob "libGL.so") is currently only recommended for workstation users that have weird compatibility requirement for "that old mission-critical CAD software over there" that requires compatibility profiles.
but all in all, the open source driver is freaking fantastic (on older R280 mine beating FGLXR in performance on most open source games).
One of the reason for AMD to recommend the opensource drivers is exactly this.
Add to that the finally managed to get DAL/DC/whatever-it's-called-now upstream in the kernel, and the recently open-source ROCm + OpenCL stack is also in the process of getting upstreamed...
It globally sounds very nice.
We just needs to see how this opensourced "official" Vuklan drivers co-evolves with the community-built "RADV" one.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Yup, there used to be, a long time ago, a period where basically you had closed-source FGLRX which was feature complete, but extremely buggy and crash-prone. And the then-recently started various opensource source drivers efforts (some by AMD opensource devs, other completely reverse engineered by 3rd party devs...) which were lacking lots of feature, though a lot more stable than the blobs.
That was about a decade ago.
In 2017, the official driver according to AMD *is* the opensource driver, it's feature complete (full support up to GL 4.5 and GLES 3.1, 4.6 should be ready soonish), maintained upstream (in vanilla kernel and mesa3d) by paid developpers including on AMD's payroll.
It's fucking stable.
(In my opinion, best experience with a rolling-release distro like openSUSE Tumbleweed - which has an up-to-date kernel/Mesa3d/LLVM and GPU drivers devs on their payroll)
Meanwhile, Nvidia are still problematic with laptops (mainly due to not playing nice with the linux API to handle weird stuff like optimus, etc.) sometime very broken (due to insisting on using user-mode-setting, on my laptop it's just plain broken whenever the laptops goes into/resumes sleep).
I personally have to resort to nouveau, which is great piece of work (given the way it was developed through reverse engineering only) but needs to constantly play catch-up and will always be lagging feature-wise.
(At least with my rolling distro, I'm getting fixes not long after they are written by the devs).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Oh, I think it is. In this era of GPU-driven machine learning, commitment == lockin. AMD is inviting people to play right down on the metal with this.
You got the wrong opensource driver.
Vulkan is about "right down on the metal" mostly in the graphics departement (through there are idea to run computations using Vulkan).
The "right down on the metal" drivers stack that got open sourced by AMD that target "GPU-driven machin learning" (and any other GPU computation), is the ROCm + OpenCL stack (with ROCm being the "down on the metal" part).
AMD has recently finished their opensourcing efforts for that one too, and the necessary component are in the process of getting integrated up-stream (so soonish, your favorite Linux distro should be able to do ROCm and OpenCL right out of the box, instead of relying on custom package carefully crafted on 3rd party opensource repos).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I, for one, welcome our new Vulcan overlords. May the Force be with you.
I guess Windows users don't get nice things.
Perhaps the greatest limiting factor in getting an open source GPU (source for firmware available) has always been implementing drivers and graphics libraries. Vulkan drastically reduced this requirement by creating a common platform for graphics libraries to execute on (see SPIR-V) and this can be a template for drivers. This leaves on two elements locked away: the firmware and the hardware itself. This is a massive reduction in labor for those who wish to bring an open source GPU to the market. It might not be the best/fastest GPU but it will be up to date and as functional as it's counterparts.
Anons need not reply. Questions end with a question mark.
If your favorite retailer drops your product, that means they no longer carry it. Is AMD dropping their video cards?
AMD for the WIN! Now we need ThreadRipper boards with ipmi!!!
It's all about getting more hashes out of their cards. By open-sourcing their drivers, more developers will throw more brain power at further optimizations for mining.
The driver is open source, but who cares? The hardware itself is closed source, can be filled with vulnerabilities, back-doors, bugs, etc. and nobody can tell.
Your head is firmly wedged up your anus if you think there is anything "open" going on here.
so you need recent AMD hardware (GCN 1.2 and up), bleeding edge distro, and also use linux in the first place, and then find some application that use it - while devs are instead wasting time adding Wayland support to some subsets of things.
I am bored by all these things that promise the moon*
* if you're lucky it will be useful in Ubuntu 20.04
** experimental
*** add boot parameter=zorglub
The only fun I ever had was with OpenGL 1. Make your game or app single-threaded and i686 for all I care, and designed to work without Internet. Then maybe it'll work? rather than an error message telling I smell, or an internet login prompt I have no intention of honoring.
Drop means discontinue
too bad your microscopic brain can't figure out that words can have more than one meaning
My company focuses on free software and every time it has been announced that AMD has released the source code we investigate only to find that it is *still* dependent on proprietary software. I have little hope today because crying wolf only works for so long. None-the-less I'll probably have someone investigate AGAIN, but I'm doubting this is anything more than a public relations stunt, as that's all its ever been prior to this.
RX480, 4GB. I've been using the FOSS drivers for about a year now and they're GREAT. I did have to compile my own kernel in the earlier days but now the ones that come with Ubuntu etc seem to work just fine out of the box.
The driver code will show how to talk directly to the hardware;
The lower level of the stack has been available for ages :
Initially in the form of "radeon.ko" a separate opensource effort progressively more and more supported by AMD themselve.
And the "amdgpu.ko" as part of a complete rewrite from the ground up by AMD devs, with the aim to enable as much code sharing as possible including between multiple drivers stacks (used by both the usual opensource driver stack AMD has been supporting, and amdgpu-pro - basically a binary libGL.so that is the current day successor of fglrx) and between multiple OSes (a little bit like Nvidia is doing, and unlike Intel which have basically 2 stacks - but rewritten from the ground up for this purpose, unlike Nvidia who have basically punched their Windows code until it more or less compiles on Linux because why spending ressource playing nice with Linux API to make laptops work ?).
Recently DAL/DC has been accepted upstream in the amdgpu frame work (the above mentioned complete stack re-write wasn't done by the usual AMD opensource crew, but by mainly by their usual multi-OS drivers crew, meaning that the quality wasn't up to level at the beginning - Linus having loudly complained that it was a giant piling of useless abstraction layering. A few rewrite and quality improvement later and it's now upstream).
All these successive infrastructures have been successfully leveraged by mesa 3d, which now serves as the official AMD driver for nearly anything (amdgpu-pro is mainly recommended for workstation users that have that weird CAD software that relies on compatibility profiles).
This is development which has been going in the open for ages, partially funded by AMD themselves.
Even Vulkan API itself isn't a big surprise. As AMD took so much time until getting all the necessary internal validation to release the Vulkan driver in opensource, independent developer have in the meantime - as a programming exercice - started the "RADV" vulkan driver, which by now ended up being nearly fully conformant and compatible with most games.
(Well, it helps that by design the Vulkan API is a very thin layer above the lower level stack).
There isn't much new radical things to be discovered in that opensourcing. Most of the big chunk have already have been opened by AMD in the past.
This is mainly a "good news" because AMD keeping up their promise to open up everything eventually (though they were slow on this last Vulkan part).
The only thing to be gained is to for the RADV developers to see how AMD official Vulkan has solved a few problems here and there that RADV might be missing. And because now the AMD driver is opensource, they could also do the same (see if tiny bits of RADV can be used as inspiration, without the legal department starting to scream that they are tainted).
you'll be able to reverse engineer this driver much more easily now that you'll have the code, and bypass it entirely for certain operations.
As mentioned above : there's not much to reverse engineer here.
Vulkan API is a very thin layer to begin with, and all component underneath (to which you would be trying to "bypass") were already open sourced since ages, because those underneath component are the exact same (kernel module "amdgpu.ko", libDRM.so, etc.) also used by the opensource driver (mesa3d) and the opensource Vulkan experiment, in addition to being used by the AMD-written software (the amgdpu-pro libGL.so for workstation users, the currently being opensourced offical AMD vulkan driver, and the recently opensourced and currently getting accepting upstream gpgpu stack ROCm and OpenCL).
It doesn't bring much new to the table, it's just AMD being true to their opening promises.
That's as "right down on the metal" as it gets, and you won't be limited to just graphics, even though this driver might be, because you'll have access tot he entire lexicon, courtesy o
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I've heard that all the required stuff for ROCm should be upstreamed by 4.16. Is that true?
I can't be of any help here. My information don't go beyond what's currently being spoken about on phoronix
(though in addition to upstreaming stuff into the 4.16 kernel, I think there are also things that need to be upstreamed into LLVM too, for the CL language compilation, etc.) : My current work in research doesn't involve much gpgpu computing, and I haven't been playing at home with openCL cryptocoin mining for a while.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
i actually like AMD, my first PC has an AMD processor and almost all replacements after that also were from AMD.
I've been using nvidia GPU's now on linux for so long, because the driver, even though closed, at least worked best. The last 2 years AMD has made so many improvements and has open source implementations that my next GPU probably will be AMD based.
At first Valve only supported nvidia for steam and steamos, but i think even they are now involved in improving the AMD oss drivers and a lot of games just work.
On a long enough timeline, the survival rate for everyone drops to zero.
When I first read the story, it sounded to me like just the 3D Vulkan driver was going to be open-sourced.
Correct, today article is about the official AMD's Vulkan driver joining the current giant open-source gang-band that has been going in the kernel.
It's just he latest bit to be added.
Then I read this and it sounds like you are implying that the whole kit and caboodle has been open sourced.
Yup, the whole rest has been open-source more or less for ages. This last bit more or less completes everything (except for a few tiny bits that are only available in the closed-source GL and which only target a few weird cases, mostly closed-source CAD software on workstations and of absolutely no relevance in the Linux open-source word)
Is the is the KMS module and the regular X11 display (2d) driver also completely open source at this point?
Yes, absolutely completely, and actually doubly so.
- First round started with a bunch of opensouce efforts, some paid by third parties (historical efforts around opensourcing the r200), some by independing reverse engineering (a few independant playing with R600), and finally, after the AMD-ATI acquisition, AMD promising to opensource everything progressively.
This started the first wave of KMS / DRI / etc. of drivers, including the "radeon.ko" that was until recently.
AMD even started paying their own opensource driver developpers, while still maintaining their own fglrx stack in parallel.
The opensource drivers have been getting progressively better, with AMD at one point deciding that mesa was going to be the official pre-HD Radeon (up to r400/r500) driver stack, and droping support out of fglrx.
- Second round came more recently around the time AMD started making GCN-based cards.
They have decide the rewrite completely the bottom part of the stack (the KMS and DRI, mostly switching from "radeon.ko" to "amdgpu.ko"), with the aim of sharing this new code among multiple implementation (the same low level stack is used since by both the opensource mesa drivers, and the amdgpu-pro, which is the successor of fglrx), and also sharing the code among multiple OSes (sharing it with Windows among other. Unlike Intel who keep two separate stacks. But by rewriting everything from the ground up for this tasks, unlike Nvidia who basically beat their Windows code until it more or less compiles on Linux and standard API and laptop users being damned).
(Though incidentally, this new re-written layer, being the first time Linux-contact for lots of AMD multi-os devs, has been criticized for its quality and has only recently reach a quality level for the last bits - "DAL/DC" to be accepted upstream without Linus puking over the quality).
The long term idea was that mesa was going to be the official openGL driver - just like they did with older radeons - and amdgpu-pro was only to be used for the weird corner cases.
Longterm promises were to opensource the other driver component, including gpgpu stacks (ROCm and OpenCL, recently opensourced to the last bit, and currently getting up-streamed), and including the Vulkan driver (today's bit).
The rest of the stack (KMS and DRI) has been opensourced for quite some time. That enabled 3rd party devs to write their own Vulkan implementation (RADV) which has now matured into being quite feature complete and conformant.
(for the record of small detail : LLVM is the compiler currently used by various drivers including AMD to get gpu-specific code compiled into GPU binaries.
e.g.: the GLSL and SPIR-V used by OpenGL shaders.
AMD gets most of it upstreamed too, with bits of the gpgpu ROCm+OpenCL and the current Vulkan code still in the process of their pull-request)
I switched from Linux to BSD years ago, but I still have a Linux rig around (Devuan rig).
You would need a quite recent distro to join the latest opensource celebration and radeon expe
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
There are a large number of middle budget laptops from HP and Dell that comes with rebranded AMD SI and CIK cards which have only GCN 1.0 or 1.1 supported. I have a HP 15-BS576TX which is a June 2017 launch which has AMD 520 discrete card. So, does many models with AMD 520/530 cards which are recognized in amdgpu as HD8xxx cards. The driver performance is most of the times laggard compared to radeon driver. I hope the developers kindly give some attention to this also. The only hope is amdgpu project with these cards. I have pkppa (Padoka stable) repo enabled in my Ubuntu 17.10 system. https://www.phoronix.com/forum...
move to FOSS,save ur nation's resources.
Just curious, which proprietary software are you talking about ? Be careful not to conflate hardware microcode (which runs on GPU state machines) with software running on the CPU. The only software running on the CPU is the on-card VBIOS, but even that is written in an interpreted bytecode with an open source interpreter included in the driver.