Vega Support Called For Pulling Into Linux 4.12, Without DC Support

[chithanh]

Will it be possible to use headless Vega with PRIME and an iGPU or other GPU in the system that connects to the display?

[dungeon]

except... https://twitter.com/elonmusk/status/840772319526113280 DC IS THE WAY OF THE FUTURE!!!!111oneone

Yeah, some billionare said... let him live on DC He can't even produce tyres of these Tesla cars without AC

[geamandura]

Yeah, some billionare said... let him live on DC He can't even produce tyres of these Tesla cars without AC

Another Elon Musk hater. The fact that he has a lot of money is not the one thing that defines him, so he's not "some billionaire".

And what is this, you just invented a new standard that Elon needs to reach? He needs to produce his tyres with DC so you take his statements on AC/DC efficiency into consideration? Maybe open a physics book yourself to have an educated guess on that subject, not based on how he produces his tyres.

There is a place to use AC and there is a place to use DC. You should be ashamed you don't understand this in the first place.

[dungeon]

Yeah Tesla should be ashamed because Edison kills animals around

I agree that there is a place to use AC and DC, it is inclusive not exclusive, blah, blah...

[bridgman]

Well it was pretty easy to get the idea that he's being openly adversarial from the language he used when AMD brought DC/DAL code for public review the first time. Add to that the fact that he's got his own Vulkan driver competing with AMDGPU-PRO and which would be made pointless overnight if AMD finally went and made it open source. In that sort of situation I'd say David should exclude himself from any AMD related decisions.

In fairness, the whole "openly adversarial" thing was a mis-communication. We were using the same "DC" name for the display code base and the specific abstraction layer that wrapped the code. Dave said "DC was never going to go upstream" (referring to the abstraction layer) but this got picked up and propagated across the internet as "the DC display code is never going to go upstream", which would obviously be bad.

I can't see it resulting in anything except better maintainable code, which I suppose is always a good thing. However the effort that's been put and will continue to be put into refactoring the code could have been spent implementing features and debugging the code rather than pleasing David & Co. When it comes down to it I don't see any real reason for AMD to build DC/DAL in such a way that it can be reused for Intel and Nouveau. You could argue that this is an attempt to force AMD to write code to improve support for hardware made by their competitors.

Yep, there is some truth to that but it is expected - just part of the cost of being upstream. One of the reasons the open source graphics stack has been able to make good progress is that there *is* a lot of code sharing between vendors in both kernel and userspace code. The trick is to find the right balance.

[Sergey]

bridgman could you please clarify if DP MST hubs will be supported any time soon with AMD hardware under linux (what ever driver works best open or closed) ?

[agd5f]

Also, is Vega with a display still going to be supported in AMDGPU-PRO? Being closed source it's not like David can do anything to stop you from implementing support there.

There is support for vega10 with displays in open source already, it's just not upstream yet.

[pal666]

I suspect in the end this will result in better AMD driver code + more shared infrastructure (ideally freesync+others) so also other drivers will benefit from that.

i suspect doing same thing in upstream repo would be even better

[W.Irrkopf]

Well it was pretty easy to get the idea that he's being openly adversarial from the language he used when AMD brought DC/DAL code for public review the first time. Add to that the fact that he's got his own Vulkan driver competing with AMDGPU-PRO and which would be made pointless overnight if AMD finally went and made it open source. In that sort of situation I'd say David should exclude himself from any AMD related decisions.

Dave calls the final shot here - but he's not making the decisions alone - not in a true open source environment. If he were to loose the trust of Intel and AMD to act as the DRM maintainer and both parties presented an acceptable new candidate to the community he would likely be replaced. But as long as he's getting flak from Linus for being not-strict-enough and flak from the vendors for being too-strict I don't see that happen any time soon ;-)

I can't see it resulting in anything except better maintainable code, which I suppose is always a good thing. However the effort that's been put and will continue to be put into refactoring the code could have been spent implementing features and debugging the code rather than pleasing David & Co. When it comes down to it I don't see any real reason for AMD to build DC/DAL in such a way that it can be reused for Intel and Nouveau. You could argue that this is an attempt to force AMD to write code to improve support for hardware made by their competitors.

That's exactly one of the core points of open source: Do it right for most/all use cases, not just yours. If you are the first, it may be easy to please all stake holders, if you are late, you have to play by the rules and code that's already there. Another point: Do you think AMD would have an open source OpenGL 4.5 driver without the huge amount of work that Intel put into OpenGL? From my point of view, the answer is a very clear "No". So who profits from this stuff, if AMD has to do things that benefit Intel and Intel has to do things that benefit AMD? It's *US*, the users any thus indirectly the companies that provide the hardware that satisfies the user's open source requirements. There is a reason why Nvidia provided open source drivers for Tegra: Because their circumventing the kernel's GPL requirement on the Linux desktop/server market does not work at all for the Linux embedded market - imagine going through the same steps before getting your in-car-entertainment system to work :-)
Last but not least, from my superficial understanding cleaning up DC (nee DAL) does not really benefit Intel or Nvidia but instead requires AMD to use/adapt existing infrastructure where it exists instead of rolling their own and replace the abstraction layer design as abstraction layers are frowned upon by the kernel community.

I don't think secrets are the issue here as any real secrets are in the code that's just been pushed. DC/DAL is after all supposed to be something supported trough out AMD's product range and not something Vega specific.

That's good to hear and it's cleared up most of the worries I had on the matter. May be a dealbreaker for the hardcore open source nuts, but not that much of an issue for someone like me who runs a set of closed source binary blobs anyway.

Agree and agree - as long as there are binary blobs that are better from a performance or feature perspective it's nice to have a choice.

[automorphism]

bridgman could you please clarify if DP MST hubs will be supported any time soon with AMD hardware under linux (what ever driver works best open or closed) ?

DP MST support depends on DC - so as far as the mainline kernel is concerned, it will be supported when DC is merged. In the meantime, though, you can use the amd-staging-4.9 kernel (make sure to enable DC when you compile it). I am currently using a DP MST hub with the staging kernel and it works fine. AMDGPU-PRO ought to work too but I can't personally confirm that.