This is actually big news.
It means that all of the major GPUs with an OSS driver share a lot of code, specifically the gallium part of the mesa project.
This means that features like OpenCL can be implemented for one driver and with minimal effort be ported to another GPU.
Does OpenCL still matter? I ask this totally from ignorance; I've heard people tell me that openCL is too slow/low level/has an obsolete model for many years but as a non-user (my work is in different domains) I can't tell if these folks are impartial or have an axe to grind.
I have a hard time seeing a meaningful future for opencl.
Apple (the original creator of opencl) has deprecated it on their platforms in favor of metal.
I think Intel has implementations, but IMO you are better off with ISPC if you are targeting a CPU.
I have a hard time keeping up with AMD's overall direction, but the latest ROCm stuff seems to focus on an implementation of CUDA AFAICT.
Nvidia apparently has no intention of focusing on opencl.
Support for opencl 2.0+ is poor. Some vendors have support, but most are partial or language only (mostly meaning c++ for compute shaders, but not the other features). IIRC, even AMDs ROCm opencl is not 2.0.
And then there are all the fpga/accelerator vendors. I don't have much experience with opencl on these, but I expect they will also move away from opencl - I'm interested to see what Xilinx does with Everest, since it will supposedly be easier to develop for than traditional FPGAs.
Vulkan compute or implementations of cuda from other vendors seem much more promising. OpenCL tried for a "one standard fits all compute," but I don't think it has worked out that well. It leads to a "write once for all platforms, optimize separately for each platform" at which point it's better to just have different standards specialized for the target. For a long time code written for one compiler wouldn't even compile with an implementation from another vendor.
Khronos, the standards body behind Vulkan/OpenCL/OpenGL, is not aiming to replace OpenCL with Vulkan Compute. But it is on the other hand introducing a CUDA-like standard, that is called SYCL that could be implemented ontop of OpenCL.
Kudos for intel for doing this. They not just open source their driver, they also work with upstream to get it pushed there. This is what every vendor should do. Looking at you, Nvidia.
Hmm, I wonder if this has something to do with Intel's upcoming dGPUs? Not necessarily a bad thing, but having a scenario with lots of code reuse among drivers and a common framework means easier/faster/better support for their new stuff. Seems like a win for both Intel and the users.
AMDGPU is a kernel driver and generally has nothing to do with AMDGPU.
r600 and radeonsi are the Mesa drivers, and both are Gallium based.
I'm not aware of a Mesa driver in a condition of usability one would consider practical not using Gallium. Freedreno, Nouveau, all AMD drivers, and the Broadcom Videocore driver are all Gallium based.
>* Supports only Broadwell and newer (Gen8+); drops support for
the older Gen4-7.5 GPUs, as well as Braswell/Cherrytrail
Meltdown/Spectre turned out not to be a reason big enough to upgrade from Sandy/Ivy Bridge, so they had to find another way to "discontinue" current users.
I guess classic i915 driver for mesa will be discontinued soon, left to bit rot and then removed from Mesa as "potentially unsafe to use, because ... memory errors cause RCE".
> Meltdown/Spectre turned out not to be a reason big enough to upgrade from Sandy/Ivy Bridge, so they had to find another way to "discontinue" current users.
I sit beside the author of the Iris driver and work on the same team at Intel. The reasoning for only supporting BDW+ has absolutely nothing to do with spectre/meltdown or trying to force people to upgrade their hardware. Such a statement really indicates that you're not familiar with the people on Intel's Mesa team.
FYI the reasoning for only supporting BDW+ is that BDW+ supports 48-bit addressing which allows the CPU and GPU to share addresses trivially. This means no relocations are required and that's a great driver simplification and performance improvement.
BDW+ also supports executing all shader stages in the "scalar" (vs the vec4) mode, which allows much better opportunity for shader compiler optimization, which is the area I spend most of my time.
Open source drivers don't work the way proprietary drivers do. For example, the Rage 128 from 1998 is still receiving updates in Mesa.[1] Before spreading unfounded conspiracy theories, you should do some research.
I still see the 3dfx driver in my mesa folder... I'm surprised now since I thought I read it was removed a year ago or so, but that might have been the kernel driver.
While the parent's post could be stated better, I share part of this fear: What about the older GPUs?
Knowing the open source attitude, they'll probably enter maintenance mode and get bugfixes but only incidental improvements. And then be supported until the last piece of hardware goes to bit heaven. Which is fine by me.
But Intel is paying for development, and of course Intel wants us to buy the latest. Who can blame them? There will be some pushing from them to stop spending money on their old stuff.
Therefore, some statement in the blog post concerning this point would be appreciated.
> For AMD GPUs, Brazos owners are SOL after they rebooted the driver design, only having partial support for what fxglr was capable of.
Doesn't Northern Islands have OpenGL 4.4 (and all but one extension in 4.5, and about half of 4.6) w/ r600? What exactly is missing relative to the last FGLRX release for NI?
There's UVD support all the way back to R600 (the first AMD chipset to include UVD), two generations before Northern Islands (which I think is what Brazos has), and there has been since before fglrx was discontinued AFAICT. I think on most distributions this support is packaged separately from the rest of Mesa, which may be why you didn't see it.
This means that features like OpenCL can be implemented for one driver and with minimal effort be ported to another GPU.