AMD's Display Core difficulties

Posted Dec 14, 2016 6:55 UTC (Wed) by mjthayer (guest, #39183)
Parent article: AMD's Display Core difficulties

I for one certainly hope that they manage to get this merged in a way which does allow sharing code between their different operating system drivers. I think that the experience gained would be valuable for everyone involved (and I would hope, though you never know beforehand, that it would end up helping the AMD team reduce their Linux work overall and improve their Windows driver into the bargain).

I also have to say that the overall mailing list exchange was very civil and constructive on all sides.

AMD's Display Core difficulties

Posted Dec 14, 2016 9:02 UTC (Wed) by blackwood (guest, #44174) [Link] (1 responses)

The linked master plan I typed up explains how to demidlayer while still being able (hopefully, but I'm positive) code. Because code sharing is very much the goal, since common code that's debug by the hw engineers at power on is pretty much the only way you can write a gpu driver these days. At least for the low-level memory bandwidth/clock stuff. Incidentally that also means checkpatch&co will be off-limits for those files.

Roadmap: https://lwn.net/Articles/709001/

AMD's Display Core difficulties

Posted Dec 14, 2016 12:03 UTC (Wed) by moltonel (subscriber, #45207) [Link]

I wonder what the relative size/complexity of the midlayers for various kernels is. I imagine that for historical reasons, the common code follows the Windows driver API fairly closely and therefor the midlayer on Windows is comparatively smaller ? Is there a way to reduce/eliminate the midlayer not just for Linux, but for all kernels ?

AMD's Display Core difficulties

Posted Dec 15, 2016 22:23 UTC (Thu) by error27 (subscriber, #8346) [Link] (1 responses)

Everyone thinks their compat code is different but I can't think of a single example that hasn't sucked...

Either way, writing a Linux driver is hard. If you just write a straight up clean implementation that's pretty hard. If you try to port the windows driver to linux without changing the windows code that's also hard and the results are messier. It also doesn't
mesh at all with Linux development style which is that the Linux kernel should be upstream and anyone else (BSD, old enterprise kernels) can be downstream if they want.

AMD's Display Core difficulties

Posted Dec 16, 2016 7:50 UTC (Fri) by mjthayer (guest, #39183) [Link]

> Everyone thinks their compat code is different but I can't think of a single example that hasn't sucked...

>Either way, writing a Linux driver is hard. If you just write a straight up clean implementation that's pretty hard. If you try to port the windows driver to linux without changing the windows code that's also hard and the results are messier. It also doesn't mesh at all with Linux development style which is that the Linux kernel should be upstream and anyone else (BSD, old enterprise kernels) can be downstream if they want.

Let's hope that this will be a first then. Daniel seems hopeful that it can be, and he has lots of experience both in the drm subsystem and in large companies contributing to it. In any case this should not be compatibility code as such if and when it is ready for inclusion, but rather (if I understand right) lower-level primitives, mainly for hardware programming, which are fine-grained enough to be shared and used by otherwise disjoint higher-level driver code for different platforms. I would naively expect that for something as complex as a modern GPU there would potentially be rather a lot of those. I would also expect, given that neither GPUs nor drm are static, that the direction drm evolves in future could be adjusted to some extent to make future integration easier.

Drivers, especially GPU ones, are complex code. Any sensible code sharing with other platforms will increase test coverage and ought as such to improve the code quality for everyone. So finding sensible ways to do that is probably worth some effort.