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
The Vulkan driver code supports back to SI (aka GCN 1.0), which launched in late 2011 and early 2012.
The code is for a userspace driver so just depends on having a suitably recent kernel driver & libdrm (already open source and already picked up by pretty much every distro on the planet). I would not call RHEL bleeding edge, although their kernel definitely has some newer bits than the base 3.10 version would suggest.
Re; having to use Linux in the first place along with an application that uses Vulkan, yes guilty as charged:)
Why do you say "the only hope is amdgpu" when radeon is the officially supported driver for your card ? Agree that you will want to move to amdgpu eventually in order to get Vulkan support, and as you know we published the first open source Vulkan support for amdgpu this morning, but other than "Vulkan vs OpenGL" I don't think you should be expecting any more performance from amdgpu than from radeon.
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.
AMD just dumped their codebase and said "Hey, there it is, do our work for us as well as pay us money for the hardware".
Citation needed.
I don't think we have ever done that with Linux drivers. We have been hiring developers to contribute to the existing open source driver projects for a decade now. If you think we dumped a driver code base and walked away from it please give me an idea what you are talking about. Thanks.
AMD has but ATI did not. ATI literally laughed in the face of open source and especially Linux.
Actually no. ATI supported and funded open source driver development from the time that Linux gaming became a possibility (~1998 with the introduction of DRI) until 2002 when we acquired FireGL and hoped that their pre-existing closed-source Linux workstation driver (fglrx) would be a good replacement. As it turned out, fglrx was OK for workstation users but never worked out well for consumer/desktop users. We looked at restarting the open source driver effort a couple of times but since that was also the point where DRM was starting to become a big and risky requirement (big penalties for failing to maintain robust DRM coupled with security-by-obscurity industry DRM model) the conclusion was that the risk was too high.
Once we joined up with AMD we picked up a second major revenue stream (CPUs) so even if the worst-case happened on the GPU side (open source drivers providing a starting point for cracking our DRM and crippling our ability to sell into OEM markets) the company would still survive. Management was willing to accept the risk so we restarted open source driver support in 2007.
Technically yes (in the sense that we only provide VBIOS in binary form) but the code is written in a portable bytecode with open source interpreter, header files are provided for all data tables, and an open source utility is available to dump out the code and data tables.
Last time I checked it was publicly available but under a fairly restrictive EULA. There's a big difference between being able to write a display driver for Windows and having the right to redistribute the API materials as part of a non-Windows driver. Also there are more OSes than just Linux/Windows involved.
The kernel and X drivers are both open source. This is an early preview driver; we're still working out where best to publish the userspace bits for libdrm, X driver and multimedia drivers. Primary goal for this early release was to start getting Linux Vulkan drivers out in public; there'll be a couple of months of tweaking & tuning (and evolving how we deploy) before we get to a 1.0-type production stack.
I would actually like some transparency from AMD for your second point. They are using a third party developer? Or maybe third party tools? I can see that maybe 5 years ago.
Nope, all in-house developers. The issue with opening up the remaining bits (at least OpenCL and Vulkan) is that the drivers are cross-OS and include a lot of OS-specific bits (for other OSes than Linux) that we don't have the right to expose publicly. Opening up the code basically involves turning them into Linux-specific drivers, typically making the OS-independent bits smaller but removing any proprietary abstractions that might have been there before, eg rewriting anything that happened to use Windows or MacOS abstractions in the common code.
As the experts for their own hardware I would expect them to hire/contract a platform expert and make their own infrastructure which would be equally open source. Publicize the developers name and simply point to him and we can rake him over the coals.
Seriously, adding *one* person isn't going to even scratch the surface. Adding 20 people maybe... we're talking about 10,000+ KSLOC of code just for OpenGL.
Yep, converting to OpenCL would probably be harder, but what we're doing here is converting to C++17 with parallel STL that can run over our HCC or CUDA NVCC.
Just curious, which 80% is that ? The open drivers are currently at GL 4.1 with a lot of the 4.2-4.5 features already implemented. Looking at the list of unsupported extensions very few of them seem to be hardware related - I could agree with maybe a few % of the hardware being supported but not 80%.
Just to be clear, this isn't "Ubuntu dropping Catalyst" it's "AMD transitioning from Linux Catalyst to amdgpu hybrid". The new hybrid driver (amdgpu open source stack plus "Catalyst" closed source OpenGL, OpenCL & Vulkan) won't be ready in time for 16.04 integration, so Canonical is focusing on the open source drivers for 16.04 launch.
So no plans to force you all to use the open source drivers... the breaking news here is "AMD in the process of replacing Linux Catalyst with amdgpu-based hybrid driver" which we announced last year.
Actually the default fan speed was set by VBIOS, and differed significantly between boards. Most boards had fan noise reduced drastically when dynamic power management was enabled (years ago for HD69xx). Some boards had higher default fan settings, and the fan control patches were intended to address those.
FYI this isn't about "dropping Catalyst", it's about moving from the closed-source Linux Catalyst stack to the mostly-open amdgpu-based hybrid stack, based on the open-source amdgpu driver stack plus closed-source OpenGL, OpenCL and Vulkan usermode drivers.
Pretty much... specifically open source drivers running on cards that happened to have very few active users and so essentially no real world test coverage. If the tests had covered even older cards that still had some active users (eg X1950) I suspect the results would have been different.
Slashdot Mirror
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
The Vulkan driver code supports back to SI (aka GCN 1.0), which launched in late 2011 and early 2012.
:)
The code is for a userspace driver so just depends on having a suitably recent kernel driver & libdrm (already open source and already picked up by pretty much every distro on the planet). I would not call RHEL bleeding edge, although their kernel definitely has some newer bits than the base 3.10 version would suggest.
Re; having to use Linux in the first place along with an application that uses Vulkan, yes guilty as charged
Why do you say "the only hope is amdgpu" when radeon is the officially supported driver for your card ? Agree that you will want to move to amdgpu eventually in order to get Vulkan support, and as you know we published the first open source Vulkan support for amdgpu this morning, but other than "Vulkan vs OpenGL" I don't think you should be expecting any more performance from amdgpu than from radeon.
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.
AMD just dumped their codebase and said "Hey, there it is, do our work for us as well as pay us money for the hardware".
Citation needed. I don't think we have ever done that with Linux drivers. We have been hiring developers to contribute to the existing open source driver projects for a decade now. If you think we dumped a driver code base and walked away from it please give me an idea what you are talking about. Thanks.
AMD has but ATI did not. ATI literally laughed in the face of open source and especially Linux.
Actually no. ATI supported and funded open source driver development from the time that Linux gaming became a possibility (~1998 with the introduction of DRI) until 2002 when we acquired FireGL and hoped that their pre-existing closed-source Linux workstation driver (fglrx) would be a good replacement. As it turned out, fglrx was OK for workstation users but never worked out well for consumer/desktop users. We looked at restarting the open source driver effort a couple of times but since that was also the point where DRM was starting to become a big and risky requirement (big penalties for failing to maintain robust DRM coupled with security-by-obscurity industry DRM model) the conclusion was that the risk was too high. Once we joined up with AMD we picked up a second major revenue stream (CPUs) so even if the worst-case happened on the GPU side (open source drivers providing a starting point for cracking our DRM and crippling our ability to sell into OEM markets) the company would still survive. Management was willing to accept the risk so we restarted open source driver support in 2007.
Sorry, thought I was logged in already.
Isn't the 6845 a display controller aka CRTC ?
It's actually the amdgpu driver rather than radeon, but the fix is already in the 4.7 kernel tree.
Technically yes (in the sense that we only provide VBIOS in binary form) but the code is written in a portable bytecode with open source interpreter, header files are provided for all data tables, and an open source utility is available to dump out the code and data tables.
Most of the numbers in that article came from proprietary drivers - all of the NVidia numbers and most of the AMD numbers IIRC.
Can you do a quick fact check ? The AMD open drivers are BSD-licensed, and are being used on FreeBSD today.
Actually AMD had Vulkan drivers from day 1 as well, but the Linux version was held up by our move from closed-source Catalyst to amdgpu hybrid.
Last time I checked it was publicly available but under a fairly restrictive EULA. There's a big difference between being able to write a display driver for Windows and having the right to redistribute the API materials as part of a non-Windows driver. Also there are more OSes than just Linux/Windows involved.
It won't magically solve the problem but will help in a few different ways.
We also have fully-open userspace drivers which actively use nearly all of the open source kernel driver functionality.
The kernel and X drivers are both open source. This is an early preview driver; we're still working out where best to publish the userspace bits for libdrm, X driver and multimedia drivers. Primary goal for this early release was to start getting Linux Vulkan drivers out in public; there'll be a couple of months of tweaking & tuning (and evolving how we deploy) before we get to a 1.0-type production stack.
I would actually like some transparency from AMD for your second point. They are using a third party developer? Or maybe third party tools? I can see that maybe 5 years ago.
Nope, all in-house developers. The issue with opening up the remaining bits (at least OpenCL and Vulkan) is that the drivers are cross-OS and include a lot of OS-specific bits (for other OSes than Linux) that we don't have the right to expose publicly. Opening up the code basically involves turning them into Linux-specific drivers, typically making the OS-independent bits smaller but removing any proprietary abstractions that might have been there before, eg rewriting anything that happened to use Windows or MacOS abstractions in the common code.
As the experts for their own hardware I would expect them to hire/contract a platform expert and make their own infrastructure which would be equally open source. Publicize the developers name and simply point to him and we can rake him over the coals.
Seriously, adding *one* person isn't going to even scratch the surface. Adding 20 people maybe... we're talking about 10,000+ KSLOC of code just for OpenGL.
Yep, converting to OpenCL would probably be harder, but what we're doing here is converting to C++17 with parallel STL that can run over our HCC or CUDA NVCC.
Something like this ? https://gpuopen.com/wp-content...
bleah, no edit function.... previous post should read "I could agree with maybe a few % of the hardware being UNsupported"...
Just curious, which 80% is that ? The open drivers are currently at GL 4.1 with a lot of the 4.2-4.5 features already implemented. Looking at the list of unsupported extensions very few of them seem to be hardware related - I could agree with maybe a few % of the hardware being supported but not 80%.
https://mesamatrix.net/
The Boltzmann (aka ROC/HSA) stack also uses the open source drivers, and that covers a lot of HW functionality even Windows drivers don't support.
Just to be clear, this isn't "Ubuntu dropping Catalyst" it's "AMD transitioning from Linux Catalyst to amdgpu hybrid". The new hybrid driver (amdgpu open source stack plus "Catalyst" closed source OpenGL, OpenCL & Vulkan) won't be ready in time for 16.04 integration, so Canonical is focusing on the open source drivers for 16.04 launch.
So no plans to force you all to use the open source drivers... the breaking news here is "AMD in the process of replacing Linux Catalyst with amdgpu-based hybrid driver" which we announced last year.
Actually the default fan speed was set by VBIOS, and differed significantly between boards. Most boards had fan noise reduced drastically when dynamic power management was enabled (years ago for HD69xx). Some boards had higher default fan settings, and the fan control patches were intended to address those.
FYI this isn't about "dropping Catalyst", it's about moving from the closed-source Linux Catalyst stack to the mostly-open amdgpu-based hybrid stack, based on the open-source amdgpu driver stack plus closed-source OpenGL, OpenCL and Vulkan usermode drivers.
Pretty much... specifically open source drivers running on cards that happened to have very few active users and so essentially no real world test coverage. If the tests had covered even older cards that still had some active users (eg X1950) I suspect the results would have been different.