The Big DRM Pull Request For Linux 4.17: 144,461 Insertions, 38,059 Deletions

[phoronix]

Phoronix: The Big DRM Pull Request For Linux 4.17: 144,461 Insertions, 38,059 Deletions

While the Linux 4.16.0 kernel hasn't even been released yet, Direct Rendering Manager subsystem maintainer David Airlie has already sent in his big feature pull request for Linux 4.17 since he will be going on holidays the next few weeks...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.17-DRM-Is-Big

[Brisse]

At least for the mentioned Fiji/Polaris GPUs, the ROCm/OpenCL stack should begin to work off the mainline kernel! I'll be trying shortly.

I've been trying but I can't get it to work on the code that is being upstreamed.

Remember seeing a comment on GitHub (wish I could provide link but I can't find it right now) stating there was an API difference in the code being upstreamed which requires an update to the ROCm bits in userspace.

Edit: Found the GitHub-comment: https://github.com/RadeonOpenCompute...iver/issues/37

The KFD ioctl API in 4.15 is different from the ROCm releases. So the user mode components from current ROCm releases will not work on upstream KFD yet.

[Figueiredo]

I know it is not under AMD's list, but is there any work in ironing out the GCN 1.0 support in AMDGPU?

[L_A_G]

I guess this is better than just delaying all of that until David's back from his holiday, but I hope I'm not the only one slightly worried by how there isn't anyone that can take over maintaining the DRM subsystem while David's not available? You'd think that for a linchpin position like lead subsystem maintainer you'd have a system with at least on person designated to take over the job if the person becomes unavailable for one reason or another.

A system where everyone is trained to be able to take over the responsibilities of their direct superiors like many armies employ may be a tad excessive, but you'd think lead subsystem maintainer would be one of those positions where you have at least one backup person that can take over when necessary?

[boxie]

I guess this is better than just delaying all of that until David's back from his holiday, but I hope I'm not the only one slightly worried by how there isn't anyone that can take over maintaining the DRM subsystem while David's not available? You'd think that for a linchpin position like lead subsystem maintainer you'd have a system with at least on person designated to take over the job if the person becomes unavailable for one reason or another.

A system where everyone is trained to be able to take over the responsibilities of their direct superiors like many armies employ may be a tad excessive, but you'd think lead subsystem maintainer would be one of those positions where you have at least one backup person that can take over when necessary?

where did you see that there is not someone who can take over?

[Rexerex]

Push code and go on holidays. What could possibly go wrong? ( ͡° ͜ʖ ͡°)

[L_A_G]

where did you see that there is not someone who can take over?

The fact that nobody's taking actually over as David goes on holiday? Knowing Linus, David and the tinyDRM debacle* it's not unimaginable that there may be some serious bugs in that code that cause Linus to reject the whole pull request altogether until David can get back from his vacation.

* David decided to push a bunch of code that had only just been pushed to him without even compile testing it, thus missing that the code didn't compile and triggered some nasty compile warnings after Linus fixed the amateur mistake that prevented it from compiling. After (deservedly) finding himself on the receiving end of one of Linus' legendary rants David said that he didn't do anything wrong and it was just Linus being stupid.

[bridgman]

Push code and go on holidays. What could possibly go wrong? ( ͡° ͜ʖ ͡°)

The fact that nobody's taking actually over as David goes on holiday? Knowing Linus, David and the tinyDRM debacle* it's not unimaginable that there may be some serious bugs in that code that cause Linus to reject the whole pull request altogether until David can get back from his vacation.

I'm guessing nobody actually read the pull request ? Dave sent the request in early because of vacation but will be reachable in case of problems and will also be back before the merge window closes.

I'll be near email for any emergency but otherwise not too engaged.
I'll likely have two days back before the end of the merge window to vaccum up any fixes.

[brrrrttttt]

I guess this is better than just delaying all of that until David's back from his holiday, but I hope I'm not the only one slightly worried by how there isn't anyone that can take over maintaining the DRM subsystem while David's not available? You'd think that for a linchpin position like lead subsystem maintainer you'd have a system with at least on person designated to take over the job if the person becomes unavailable for one reason or another.

A system where everyone is trained to be able to take over the responsibilities of their direct superiors like many armies employ may be a tad excessive, but you'd think lead subsystem maintainer would be one of those positions where you have at least one backup person that can take over when necessary?

Daniel Vetter is quite capable, and is effectively co-maintainer. What's the problem?

[FireBurn]

I've been trying but I can't get it to work on the code that is being upstreamed.

Remember seeing a comment on GitHub (wish I could provide link but I can't find it right now) stating there was an API difference in the code being upstreamed which requires an update to the ROCm bits in userspace.

Edit: Found the GitHub-comment: https://github.com/RadeonOpenCompute...iver/issues/37

I don't think they'd be allowed to upstream it, if there was no userspace code that uses it. To be fair the instructions to build the OpenCL stuff leaves a lot to be desired. I was playing around with it and they don't make it easy. Which bits are required, can I use my system LLVM from Git/SVN?