AMDGPU DC Display Code Tacks On Another 28 Patches

[starshipeleven]

What's RADV then? A Directx driver?

RADV isn't from AMD, he was complaining about the lack of AMD's.

[FireBurn]

If you look at the patches in https://cgit.freedesktop.org/~agd5f/...aging-drm-next you can see that they have been reviewed and ack'd etc. Whether or not it's ready for merging or not will be up to AMD, Alex and Dave.

As for the TODO list at https://cgit.freedesktop.org/~agd5f/...aging-drm-next some of these items don't need to be done before merging

Anyhoo fingers crossed for 4.15

[OneBitUser]

What's RADV then? A Directx driver?

An "independent" open source effort.
I think he meant that AMD still hasn't open sourced their proprietary Vulkan driver after 19 months, even though it was promised.

[rene]

An "independent" open source effort.
I think he meant that AMD still hasn't open sourced their proprietary Vulkan driver after 19 months, even though it was promised.

however, I rather prefer independent open source efforts, as the vendor's Windows code often does not live up to such a great quality, ... :-/
also usually improves long term maintenance and support, ...

[L_A_G]

An "independent" open source effort.
I think he meant that AMD still hasn't open sourced their proprietary Vulkan driver after 19 months, even though it was promised.

I don't think they ever gave a timeline for that and seeing how much additional work getting DC mainlined turned out to be you honestly can't blame them.

Seriously, if you don't like that there's always RADV and if you're not satisfied with the current state of it maybe you should roll up your sleeves and fix it yourself? It is an open source project after all...

[eydee]

RADV isn't from AMD, he was complaining about the lack of AMD's.

Does not originate from AMD, but it's AMD developers who are working on it. If that's a problem, we could discard all Mesa, because Mesa does not originate from AMD.

[ermo]

I don't think they ever gave a timeline for that and seeing how much additional work getting DC mainlined turned out to be you honestly can't blame them.

Seriously, if you don't like that there's always RADV and if you're not satisfied with the current state of it maybe you should roll up your sleeves and fix it yourself? It is an open source project after all...

Meanwhile in the real world, I'm sure there are people and businesses who would love to be able to sponsor the AMD driver development stuff (via Patreon or something similar) if it meant getting support for the newer GPUs.

I think it's pretty clear by now that not everyone wants to work on GPU driver code just to have the AMD products they buy be properly supported.

[Brisse]

Tried linux-kernel 4.13 patched with AMDGPU DC last week on my Ubuntu-GNOME 17.04 system with R7 1700X and R9 Fury.

- System randomly crashed about once per 24 hours
- Display port audio seemed to work in most cases, but my music library in Rythmbox was completely silent which makes me think it doesn't work for 44.1khz content
- Switching display modes was buggy as hell. My monitor enables 60, 90, 120 and 144hz (@2560x1440), but only 60 and 120hz actually work as they should.
- Couldn't get Freesync to work at all, despite xrandr reporting it as enabled.

I'm back on vanilla Ubuntu kernel 4.12.11 again. It's missing those features we all want, but at least it's stable.

[airlied]

Radv on cik, vi and Polaris passes as many conformance tests as pro as works better in many games, not sure what vash63 is smoking.

[geearf]

Does not originate from AMD, but it's AMD developers who are working on it. If that's a problem, we could discard all Mesa, because Mesa does not originate from AMD.

Which AMD developers do you see doing most of the work on radv? I'm very curious here.