Slashdot Mirror
AMD Building New GPU Linux Kernel Driver To Unify With Catalyst Driver
An anonymous reader writes: AMD is moving forward with their plans to develop a new open-source Linux driver model for their Radeon and FirePro graphics processors. Their unified Linux driver model is moving forward, albeit slightly different compared to what was planned early this year. They're now developing a new "AMDGPU" kernel driver to power both the open and closed-source graphics components. This new driver model will also only apply to future generations of AMD GPUs. Catalyst is not being open-sourced, but will be a self-contained user-space blob, and the DRM/libdrm/DDX components will be open-source and shared. This new model is more open-source friendly, places greater emphasis on their mainline kernel driver, and should help Catalyst support Mir and Wayland.
That is part of it, to be sure...
The other part is that many trade secrets lay within those binary blobs...
It isn't just you they don't want seeing all that, nVidia is on their radar as well...
Plus, keep in mind that some of their technology isn't theirs, cross licensing and patents protect many things in video graphics, some of it isn't theirs to release...
----------------
It is at least a step in the right direction.
I suspect that their real concern is making older cards backward compatible with new features. Do you really think last years video card can't support the newest version of DirectX? Remember the Intel chips that you could upgrade by simply soldering 2 pins together? I suspect that THAT is what they are really afraid of. The mod community figuring out how to make upgrading less important.
Call me when RedHat ships systemd-catalystdriver, until then I'm not touching this old, crufty technology that's clearly not ready for the Cloud.
I want to delete my account but Slashdot doesn't allow it.
Moving binary blob into user space while keeping the kernel driver free would be an excellent move. I'm of course assuming that this "open source" driver will actually be free software like the current X.org driver.
The question isn't really whether last year's card can support this year's features; but whether they can do so remotely adequate speed. Recent-ish cards are turing complete on their own, and nothing forbids doing some amount of work on the CPU by building that into the driver. Frame rate probably won't be pretty, though.
"The other part is that many trade secrets lay within those binary blobs.."
Gimme a break. By now other companies have come up with the same algorithms and processes for optimal execution of specific commands on given silicon. The shit shouldn't be patentable or trade secret in the first place as it's all math.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
"New DX versions often require new hardware"
And this is why OpenGL is superior, and always has been.
At roughly 33% less power/cycle cost vs DX which requires being sent through the CPU two or three times instead of going directly to the GPU.
Plus, OpenGL can have anything added in - you're stuck with DX features.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
"future generations of AMD GPUs"
The "future" GPUs support protected mode and preemptive context switching, first of their kind. You will actually be able to pass a virtual memory address to the GPU, and it will respect that virtual memory space just like the CPU, and can even issue page faults to have the kernel load from the page file. Their new GPUs will fully integrate into the virtual memory system. I'm sure this has a lot to do with their lack of backwards compatibility.