AMDGPU DC Display Code Ported To GCN 1.0 "Southern Islands" GPUs

[chithanh]

The only problem with this is that they all doing this because AMD is either years too late

No. They are doing this because they can.
If game developers run into driver trouble with the proprietary drivers, the only recourse would be to report a bug to the vendor and hope for a fix (which may or may not come soon, may or may not apply to legacy cards, etc.), or to include a workaround in the game code.
With mesa, they can submit a patch for inclusion in mainline, and before long all distros will have that included.

[agd5f]

The only problem with this is that they all doing this because AMD is either years too late (see radv, now DC for SI) or just dont have the manpower to fix bugs (see current state of Mesa RadeonSI, https://www.gamingonlinux.com/wiki/Games_broken_on_Mesa).

We had full modesetting support for SI (including audio) in radeon and amdgpu, it just happened to not be part of DC. It's nice to add SI support to DC, but it certainly hasn't been a blocker for SI functionality.

As for game bugs, we can't test every game. We focus on the ones that are a priority for us and we work on the others as best we can. The same thing happens on other OSes and for other vendors, you just don't see the interactions because they generally go through direct partner channels. Because the driver is open source we do as much as possible in the open which means using public bug trackers and mailing lists. This doesn't make the open drivers any more or less buggy than others, you just see the sausage making process more with open source. Open source also gives anyone the ability to add new functionality or fix bugs if they have a particular itch to scratch.

Whats the current status of the control panel actually? (next year or after next year?)

As has been stated before, we have no plans to do a control panel. Michael brings this up from time to time to stir things up, but there are no plans on our part. We had a control panel for fglrx, but it was a nightmare to keep up to date. The problem is, every desktop environment stores user preferences in a different way so there's no single way to support every desktop. Plus, things are constantly in flux so it was always a challenge to keep up with preference changes in each desktop environment. If we just picked a couple of environments to support, we'd catch flack for not supporting others or not being integrated into the look and feel well enough because we picked a particular toolkit. Moreover, most of the infrastructure on Linux is common across GPU drivers (hwmon for sensors, KMS for modesetting, drirc for 3D settings, etc.) so it would really make sense to write a common GPU configuration tool for all GPU drivers. That would cover most of what I assume you care about. Even with that, you'd really need buy in from desktop environments for proper integration and look and feel.

[Strunkenbold]

As for game bugs, we can't test every game. We focus on the ones that are a priority for us and we work on the others as best we can. The same thing happens on other OSes and for other vendors, you just don't see the interactions because they generally go through direct partner channels. Because the driver is open source we do as much as possible in the open which means using public bug trackers and mailing lists. This doesn't make the open drivers any more or less buggy than others, you just see the sausage making process more with open source. Open source also gives anyone the ability to add new functionality or fix bugs if they have a particular itch to scratch.

First off, thx for your reply. I think it is a good thing that we can talk about this in the forums. And even if my next sentences sound a little bit harsh, I still like to say thanks for your work cause I think its the right way to develop a driver in the open source world, its just you cant do this with 1-2 devs alone.

Now if I get your message correctly, you say that the quality of Mesa Radeon driver is actually not so bad because the process is open and we can see problems because of public bug trackers.
Well let me tell you that I never encountered so many problems with different games like I experienced with the Mesa driver in the last two years Im using it. I never had even close as many problems with the Windows AMD drivers.
Yes there are always problems because of game ports not doing what the OpenGL specs says. Porters develop for nvidia, ignore Mesa. So the situation is complicated.
But there where a lot of bug reports and still are bug reports who have zero progress for years. No one is working on these. Actually you would expect some kind of QA taking on these reports within weeks. But you can be happy if you got a response in some months.
Given the release cycle of LLVM is twice a year and Mesa is also quite slow, this rate is really poor for the users.
Let me give you two examples:

https://bugs.freedesktop.org/show_bug.cgi?id=99923

Reported in February 2017, bisected to a LLVM commit in September 2016, fix probably appearing in LLVM 8.0.0 releasing spring next year. Backport? Probably not.

https://bugs.freedesktop.org/show_bug.cgi?id=100069

Reported in March 2017, problem probably existing since OpenGL4.5 was enabled, last message: "known problem", no response since that...

I dont blame the ones who currently work on Mesa, they need to think about how they spend their time. And if its an old game or old generation of cards affecting things get lower priority. But this make things appear like AMD Mesa developing is like a hobby project.

[Strunkenbold]

No. They are doing this because they can.
If game developers run into driver trouble with the proprietary drivers, the only recourse would be to report a bug to the vendor and hope for a fix (which may or may not come soon, may or may not apply to legacy cards, etc.), or to include a workaround in the game code.
With mesa, they can submit a patch for inclusion in mainline, and before long all distros will have that included.

On one hand its a good thing, I agree.
On the other hand, developers get hired to work on company projects. They shouldnt need to work for another company while getting paid for another project.
Of course if writing a bug report makes more work than writing a patch all is fine.
But I dont think thats the reason feral is writing patches. Its more like "if we dont do it, no one else fix it for us. Or it takes ages." And thats the problematic aspect.

[Strunkenbold]

As has been stated before, we have no plans to do a control panel.

Thx for clearing this up.
If that counts and just for the record, I dont need a control panel who integrates in my DE.
Really I would be more than happy if AMD just ports the Windows control panel.

But I guess the general DRI config will take some years to appear then.

[Strunkenbold]

Who cares point releases when you can use rolling Mesa and LLVM git.

https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

Speculating a bit here but I think 90% of the distro users care, as they wont install any experimental packages nor compile from source.
If your general solution is that people should compile from latest HEAD, I wonder why we spend time and resources on release managing?
Lets just make a release every year on Christmas!

[Strunkenbold]

See https://github.com/BoukeHaarsma23/WattmanGTK

Thx! Lets pray AMD supports development or we have another dead born project.

[chithanh]

They shouldnt need to work for another company while getting paid for another project.

I think you may have misconceptions here about how Linux/FOSS works.

The Linux community is not just a vendor cartel. Fixing the problem in Mesa will benefit the whole community, not just a single group of customers of one vendor. Feral asked on Reddit a while ago what was each user's personal highlight of 2017, and among the most popular responses stood out "Feral contributes to Mesa".

I can fully understand the criticism if it the work benefits some ARM licensee like Allwinner who have to be dragged screaming into providing source code for their GPL blobs. But this is AMD, who are mostly friendly to the FOSS community.