AMD hardware support in Manjaro

amd
amdgpu
manjaro
graphics
radeon

#61

Well, I don’t see Linus or the devs merging it anytime soon… (And I wish I was wrong…). I don’t think the display code is still in beta, it should be good if it’s stable, new features and further development are just new versions, so that shouldn’t be why their not merging it.

Yes, but that’s cause it’s not modular and that’s most likely the reason why they won’t merge it. In short, if it’s goes against KISS :smile:


#62

You should definitely follow the discussion on phoronix.
There are AMD employees there that also comment in the discussions.

The main part why it is not merged yet is because it has HALs in it and upstream maintainers don’t like that. AMD is currently working on removing them.


#63

Yes, it’s been a while since I read phoronix and the like. When I finish work I’ll go read it.

That’s really good news, I though it would never going to be merged… We just have to wait


#64

https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-PULL-REQUEST

Looks like display code is going to mainline Linux 4.15 already! :heart_eyes:


RX Vega 64
#66

I just read it on phoronix and I was coming to announce it so happily, two of you beat me to it!

That’s awesome! :yum:


#67

It get’s even better:
https://lists.freedesktop.org/archives/dri-devel/2017-September/153482.html

More important is whether merging a new driver base will benefit the overall subsystem, and here this primarily means whether the DC team understands how upstream works and is designed, and whether the code is largely aligned with upstream (especially the atomic modeset) architecture.

Looking back over the last two years I think that’s the case now, so

Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch>

for merging this pull.

and:

And yes some of the files are utterly horrible to read and not anything close to kernel coding style standards. But that’s the point, they’re essentially gospel from hw engineers that happens to be parseable by gcc

From what I understand, it is now accepted upstream!


#68

I’m very much incredibly looking forward to Linus comment on this staggering amount of new code.


#69

and now, with resources free, AMD is going full speed on further development:
AMD Hiring LLVM Engineers for working on ROCm

@Tids From the comments on the display code news:

For OpenCL, you can use the AMDGPU-PRO OpenCL stack on AMGDPU without any issue, it’s what i’m using right now.

Would that be possible for Manjaro? Or would it still violate some rights?


#70

Also, I read somewhere something about Linux performance being on par with Windows? Is that what’s going to happen once the display code is merged? Or after some tweaking?


#71

that already happened last year, depending on the game: https://www.phoronix.com/scan.php?page=article&item=amdgpu-win10-fury&num=4

That benchmark was done with kernel 4.7 and mesa 12.1 - now we are at kernel 4.13 and mesa 17.2 with a whole lot of additional improvements and full OpenGL 4.5 (that was still not there in 12.1).

Edit: Found a newer one that also shows that full opensource mesa is better then mixed-source amdgpu-pro:
https://www.phoronix.com/scan.php?page=article&item=radeonsi-beats-wingl&num=2


#72

No change. Windows is using the same DC code with the catalyst driver and thats not a performance thing, just a Displaymanagement thing.

Not possible, we’re simply not allowed to distribute the closed source openCL driver. I dont know the state of ROCm right now. Is it already completely open now?


#73

I don’t think so - but with that news, I guess things will go a lot faster soon:


#74

Mesa is already faster than AMD’s closed opengl implementation since… I dunno, almost the eternity. Be it windows or linux.
If instead the comparison is between windows dx11 and mesa GL (assuming the game was properly ported), that should also becoming a thing as of lately.
DC has nothing to do with performance though.


#75

Ok, if DC has nothing to do with performance, then the drivers are the ones that perform better or worse. Are windows and linux drivers the same? Or that’s only for the DC?

Anyways, the important thing here is that linux is catching up and starting to be (harder?) better, faster, stronger! :grin:


#76

Its only the DC and ROCm (OpenCL) that will be shared between linux and windows. The more important things (for us) OpenGL and Vulkan will not be shared. I mean, for vulkan it would be possible, if AMD finally releases the Volkan driver as opensource, like they wanted to - but I’m not so sure that this will ever happen, when now Valve and Google are working on the free RadV-Vulkan driver…


#77

Didn’t Khronos already did that?


#78

A specificaton is not a driver. So no :joy:


#79

What about the part that says:

[…] and Khronos members released Vulkan drivers and SDKs on the same day.


#80

sure many of them do release drivers, but proprietary driver :wink: Just intel and the AMD Community (not AMD by itself) create opensource Vulkan implementations


#81

OK while GCN 1.1 “just works” in the old way (blacklist radeon, force amdgpu), 1.0 was broken for Linux 3.13 and newer. This is now fixed.

I really wanna play with

options radeon si_support=0
options radeon cik_support=0

This would help to unblacklist radeon and make it possible to run a radeon+amdgpu-experimental-prime setup (wich is impossible right now), but I also dont wanna ■■■■ around with users setups of amdgpu-experimental and this would be a big change, a Xorg-breaking, kernel-panic-creating change maybe :thinking: