AMD Is Exploring A Very Interesting, More-Open Linux Driver Strategy

[pingufunkybeat]

What AMD might do is to convert the existing open source driver to serve the dual purpose of providing system calls for both the open and closed user-space drivers. The question then is whether this is achievable without requiring custom system calls for the closed source driver. On the face of it, it might seem questionable - if they could have implemented the closed source user-space driver using only the existing kernel functionality in the first place, then why would they have bothered to write the closed kernel driver? But perhaps they had other reasons e.g. "protecting IP". Either way, Linus is unlikely to accept any patches that are aimed solely at providing functionality for a closed source user-space driver.

But this is exactly the point. radeon kernel driver is not a shim for a closed-source blob, and it has a fully functional MIT-licensed userspace driver.

The idea is that the closed source blob would use exactly THAT. And that any additional functionality would also find its way into the open userspace driver.

[oibaf]

I noticed previously unknown (on open source code) AMD developers submitting patches to glamor and mesa video code, see for example:

http://cgit.freedesktop.org/xorg/driver/glamor/commit/?id=e734e1b621c03aeb1c7ba6b2485b7e71c8b008b6

http://cgit.freedesktop.org/mesa/mesa/commit/?id=0206f0b3d4923411036711d9e7b31e33cd793a4e

Are they catalyst developers using some open source driver features (glamor, mesa G3DVL)?

[bridgman]

Are they catalyst developers using some open source driver features (glamor, mesa G3DVL)?

Not exactly, but sort of

Tim (twriter) already managed a team of developers who were supporting embedded customers using both open and closed drivers; Leo and Samuel were part of that team. When Tim took over the open source gfx team from me (effectively combining the two teams) the next logical step was to have everyone contributing directly to the open source stack rather than working with/through the open source gfx developers.

So at the moment it's just "more developers working on the open source stack"...

[blackiwid]

Either way, Linus is unlikely to accept any patches that are aimed solely at providing functionality for a closed source user-space driver.

What do they all the time for Nvidia? They accepted a nvidia patch to change stuff (adding NON-GPL) Strings or something similar for Nvidia blob beeing able to switch between internal gpu and external.

And that 1-2 months after showing the middle-finger to this Nvidia.

[wizard69]

In fairness, we did send a Kaveri system. Not a "card" technically, but it is hardware

Gee I could use one of those. 😋😋😜😜

[wizard69]

Last time I looked at fglrx kernel blob in debugger, there were a lot of c++ mangled symbols. So first if they want to modify foss radeon kernel module, adding code from fglrx and then push changes upstream, they have to rewrite kernel c++ code to c. Linus will never accept c++ in kernel...

Never is an extremely long time! With the improvements to C++ and the advancements made compiler wise I can see future acceptance of C++ in portions of the kernel code base.

[wizard69]

AMD GPUs are completely irrelevant in HPC environments. Also their CPUs fast are getting to be the worse choices from every perspective. Recently at my university the HPC group replaced all AMD hardware with xeons and added xeon phi cards for testing. Yeah... Everyone experienced speed increases from from two and up to ten times depending on workload.

Which is kinda sad considering that AMD had big revenues from HPC parties several years ago.

How old was that AMD hardware? In any event I think you are blowing hot air here, AMD cards reliably run OPENCL code bases faster than just about anybody.

[wizard69]

Can somebody tell me how win, mac, and android are handling the situation with the closed source drivers and why is it such a pain in the ass to do the same thing for desktop Linux? Is it because of the outright hostile behavior of the kernel devs towards anything and everything closed source, or is it simply an engineering problem to which nvidia dedicates more engineering effort and amd very little?

Well no one ever bought a Mac for outstanding GPU performance. I don't know how well the drivers are working on the new Mac Pros but Apple has never focused on high performance opting for correctness instead. Interestingly Apples iOS devices have very good performance in the GPU codes.

I'm not sure I'd call the Linux developers hostile to binary blobs, there problem is that if something goes wrong there is nothing they can do to understand the problem and correct it. The preference is for open source so that all Linux code is supportable.

[wizard69]

Nice move AMD!

It isn't often I read a long thread on Phoronix end to end but I must say this is about the best thing I've heard all year from AMD. I'm really hoping this turns around AMD GPU support making it the best solution on Linux by a long shot. I'm also hoping this means more attention to OpenCL support.

So all I can really say right now is good work AMD, I really hope this works out as planned and happens quickly.

[Anarchy]

How old was that AMD hardware? In any event I think you are blowing hot air here, AMD cards reliably run OPENCL code bases faster than just about anybody.

Hehehe... OpenCL development is in fact done on AMD cards because they're highly compliant to the standard in contrast to nvidia, but because opencl is relatively new in HPC it's not widely used. People still prefer nvidia cuda because there are a lot more libraries for it, which are higly optimized.

One thing I know is that Intel has been pushing like crazy their new Xeon Phi cards. They're basically force feeding us with them and if David Kanter from realworldtech.com (Knights landings details article) is right about the next version of Phi then we'll see even bigger push by Intel.

Whether we'll ever see opencl beat nvidia cuda is questionable. Scientists are very conservative and they don't care about opencl vs. cuda vs. something else, unless it's absolutely obvious that one is significantly better than the othersthen even than it's not enough. Spending time on refactoring "old" code is time not spent on science. For example I still use F77 code first written in the eighties. 😂

The amd hardware was second revision bulldozer opterons. FWIW they update or replace the compute clusters every second year or so. But this time they opted for xeons mostly because they science guys wanted intels. Anyway, I wish it was blowing hot air. :-(