New OpenGL Driver for Intel Gen8 GPUs Merged into Mesa
lists.freedesktop.org
lists.freedesktop.org
This means that features like OpenCL can be implemented for one driver and with minimal effort be ported to another GPU.
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.
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.
uhhhhhh i965 (which is replaced by Iris but unfortunately only for >=Broadwell, at least for now)
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".
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.
[1] https://bracecomputerlab.com/2018/06/08/selecting-ati-techno...
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.
The old driver is no longer compatible with modern distributions.
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?