I Had A Tough Time Deciding What GPU To Use On My Main Fedora Linux Workstation

[illwieckz]

Mainlining DAL/DC should be AMD Linux driver team's first and utmost priority

Michael has proven mainlining DC is not a priority at all, neither a need: he chosen the driver that can't be mainlined and will never be.

Michael is just saying AMD is losing time trying to mainline DC because that's not a criterion decision.

[note: I disagree with this statement, but that's the statement]

[schmidtbag]

For GUI itself, gtk builder would take care of everything, and C is just to connect it and to create action, problem with Python from what i saw, is that after few years, application would stop working because it's already moved to another version, or something changed so you'll have to change code, at least that's what I'm getting from outside observation, could be wrong tho, but C seems easer (better documented) for gtk+ developement, and most of the gnome applications are written in C (from what I saw, could be wrong again).

To my knowledge, GTK Builder can be used for any language, including Python. I personally never used it, but several years ago I used Glade, which was very Python-compatible. As to whether GTK is easier to develop in C, I'm not sure about that. I'm not saying you're wrong, but the nature of C itself already increases the difficulty level. I completely understand what you mean about documentation, but once you figure out the gist of how the Python GTK library works (or any Python library that was ported directly from C) it becomes pretty easy to get by with the C documentation. For many Python libraries, the learning curve starts off very steep but plateaus almost immediately.
Just to go on a tangent - I personally hate how many Python library tutorials are done. I really hate it when developers unnecessarily add classes and decorators to their tutorials or example files. Usually the first thing I do when trying to understand how something works is I make the code as short and simple as possible without removing functionality. There were times I reduced a 100-line example script down to 30. That's ridiculous.
I don't blame you for finding Python overwhelming at times, because some people don't know how to just get to the point and make code readable to newbies. When you compare C to the scenario I brought up, it is totally understandable why you'd think it might be easier. The fact of the matter is, Python isn't nor shouldn't be that difficult. Devs need to stop treating it live Java.

Python's versioning is irrelevant. The only major breakage in Python libraries in the past decade was when version 3.0 came out. Though pretty much every library worth using is available on Python 3.x today, version 2.7 is still kept up-to-date and is widely available. There's also a script available that can convert Python 2 code to Python 3. It isn't flawless, but the differences in the versions are pretty minimal anyway. For a 500 line code, it might take you an hour or 2 to get it converted.

If you want to get into Python GUI coding, personally, I would highly recommend getting into Qt. The Qt Designer is a very powerful and intuitive tool, there are tools that can generate your design into a Python script for you, and Qt is much easier to implement in Python. I once created a pretty advanced tool that would draw live graphs from data it collected over a serial port, and you could detach some of the graphs into its own sort of resizable pop-up window. I've tried libraries for GTK2, GTK3, and TK for Python but Qt was much easier and more advanced. But, if you use GNOME, I can see why you'd prefer GTK.

[leipero]

schmidtbag Everything you said applies well to someone who actually knows what the hell he's doing, not to idiot like me . Yeah, builder with python is not well documented, I mean for someone who's programmer, it's easy to connect the dots if he's familiar with python (or C for that matter), so yeah, it's possible in any language as long as person knows what she's doing. Since GTK+ use headerbar (CSD) and the idea was to put "system wide" and "per user" settings, it would look really nice if that's an CSD option, and it would integrade well in both GNOME and other DE's (even QT based, such as KDE). For example, even tho I am GNOME user, every single distribution with KDE I've tried integrated quite well gtk+ applications, I can't say the same for most distributions with GNOME, it's actually the opposite most of the time, QT based applications are not integreted as well "out of the box" and often it requires user intervention to make them look good. Another problem is that if choosing qt over gtk+ CSD wouldn't be available and whole concept of GUI design is not as what I've wanted, while if using gtk+ it is possible to make GUI with an option "use, or not CSD", so it would look good even in QT (KDE) or non-CSD gtk+ based desktop environments (such as MATE, Cinnamon, XFCE etc.). From that perspective it makes sense to go with gtk+, even if qt can be potentially easier to do.

[schmidtbag]

schmidtbag Everything you said applies well to someone who actually knows what the hell he's doing, not to idiot like me . Yeah, builder with python is not well documented, I mean for someone who's programmer, it's easy to connect the dots if he's familiar with python (or C for that matter), so yeah, it's possible in any language as long as person knows what she's doing.

You have to start out small. Even if you're an experienced programmer in another language, you're going to have a hard time switching to another language and immediately jump into something as advanced as a GUI, regardless of how simple/easy the language as a whole is. This is especially true if you are self-taught.

Since GTK+ use headerbar (CSD) and the idea was to put "system wide" and "per user" settings, it would look really nice if that's an CSD option, and it would integrade well in both GNOME and other DE's (even QT based, such as KDE). For example, even tho I am GNOME user, every single distribution with KDE I've tried integrated quite well gtk+ applications, I can't say the same for most distributions with GNOME, it's actually the opposite most of the time, QT based applications are not integreted as well "out of the box" and often it requires user intervention to make them look good.

Makes sense. And yeah, GTK is arguably the Linux default toolkit, so it is very compatible. Keep in mind many Qt-based applications are designed to be integrated with KDE. If you install a KDE program on GNOME and it wants to install any KDE libs, you may want to avoid it. In other words, that's the fault of the KDE devs, not Qt's fault. Most DE-independent Qt applications work very nicely with other DEs. Also, the CSD issue (if I understand correctly what you're referring to) isn't apparent across all Qt apps; probably just the KDE ones. For example, the Qt frontend for VLC blends in well. I don't know if I'd say it integrates well with GTK-based environments, but it doesn't stick out like a sore thumb.

Part of me wonders if GNOME is the problem here. GTK apps work fine on any environment, but not all Qt apps work fine on GNOME.

[leipero]

schmidtbag Yeah, I get that, but it requires time regardless, for experienced ones, it take considerably less time i guess. As for Qt and GTK integration, that as well might be problem of GNOME, I really didn't used other DE's that much so i could say for sure, but it is more likely problem of distribution packaging and configuration, for example Ubuntu (back in versions 15.04, 15.10 (if i remmember corectly) did not came with qt4 (at the time) libs and configuration, so applications such as Clementine for example did not integrate at all, and since I use Clementine as my main music player regardless of DE, i had to install and configure manually, on the other hand "Linux Mint" 17.1 (or whatever was the version at that time) did pack all those libs "out of the box" and was configured properly, so it required no input from the user, just install Clementine and everything looks as it should. And yeah, same goes for VLC, even with VLC there was a problem in some Ubuntu distributions.

As for CSD, I think KDE team works on implementation of it, GNOME (or GTK) uses "headerbar" for it, good example could be "Software" application from the GNOME 3, it have exactly the way I was thinking of, those "tabs" are in headerbar (I think it was Search, installed and updates, 3 options, not sure, I use Pamac for updates and software so I can't check it now), Pamac on the other hand uses CSD also in similar fashon, the problem with Qt is that sort of thing is impossible to do at the moment, to my knowledge, so far it's WIP, and I'm sure it will be in future. While using GTK+ aside from integration, you can have "switch" to turn on or off "CSD" or even use some sort of auto detection of DE (plus option regardless if user want to change it for some reason). That type of "switch" is already used in Rhythmbox "alternative-toolbar" plugin, so whoever does that doesn't need to reinvent the wheel, just apply same/similar approach there.

[OneBitUser]

Yeah, I'm gonna get in trouble for that...

By the way...
How is the "plumbing" work in MESA going for Radeon Software?
Is the availability of Radeon Software on Linux dependent on the DC/DAL development that is not mainlined yet?
Or does it also have other requirements on the amdgpu side as well?
In short: about how much of the foundations are as of yet missing?

[schmidtbag]

I really didn't used other DE's that much so i could say for sure, but it is more likely problem of distribution packaging and configuration, for example Ubuntu (back in versions 15.04, 15.10 (if i remmember corectly) did not came with qt4 (at the time) libs and configuration, so applications such as Clementine for example ..... And yeah, same goes for VLC, even with VLC there was a problem in some Ubuntu distributions.

Ubuntu alone could be the reason for your troubles with Qt. I'm not sure if you're aware but Canonical made it very difficult for Kubuntu to exist, particularly around 2015. As a KDE user myself (note, that isn't why I like working with Qt in Python - I used GTK first, even as a KDE user) I use Arch Linux, as it seems to be maintained very well, to the point that I'm able to use Wayland on a daily basis. When I'm not using KDE, I use Debian.

As for CSD, I think KDE team works on implementation of it, GNOME (or GTK) uses "headerbar" for it, good example could be "Software" application from the GNOME 3, it have exactly the way I was thinking of, those "tabs" are in headerbar (I think it was Search, installed and updates, 3 options, not sure, I use Pamac for updates and software so I can't check it now), Pamac on the other hand uses CSD also in similar fashon, the problem with Qt is that sort of thing is impossible to do at the moment, to my knowledge, so far it's WIP, and I'm sure it will be in future.

To my understanding, many of these features you want are GNOME specific, so it is understandable why Qt (or really anything other than GTK3) aren't appealing to you. I find it completely reasonable why you want them. For me personally, unless I'm developing a DE-specific app, I prefer my app to be as cross-platform as possible. GTK is a solid choice for x86 on Linux or BSD (in which case a replacement to driconf would be fine being GTK based), but you start encountering issues once you stray from that. Since Python also makes your app more readily cross-platform, using that along with Qt5 can (in my opinion) make your app as portable as possible with the least amount of effort. Pretty much the only place where you'll get absolutely nowhere with python+Qt is iOS.

Anyway, if sticking with the GNOME ecosystem is what suits you best, maybe you were on the right track all along, where GTK and a language other than Python might be the best route for you.

[leipero]

schmidtbag Could be Ubuntu, it's just a dependencies problem (for Qt4 at least) and configuration problem for Qt5. Arch on the other hand have to be configured manually, so no one could really complain about something missing, since it is what you make of it. It's true Arch doesn't patch software, and Ubuntu seems to go down that path with moving to GNOME, but even on Arch if you install just gnome and gnome-extra groups you wouldn't get integration with Qt out of the box, you have to do it manually, for Clementine and such Qt4, and for VirtualBox now it's Qt5 style plugins and configure it in environment, but for Arch "do it yourself" philosophy it's fine, other distributions that ship with GNOME (or non-KDE) DE's should do it for users IMO.

While CSD is GNOME choice of doing thing in recent years, with GTK+ toolkit CSD can and will work on other DE's, it will just look "out of place" in non-CSD DE (sucha s Cinnamon, MATE, KDE, XFCE etc.), the reason why anyone would choose gtk over qt for such tool that is aimed at "everyone", is because if using anything other than gtk+ GNOME users are sort of "left behind", while if using gtk+ KDE users wouldn't be left behind (as long as option for disabling CSD is offered, or even better auto detection + option). Personally I love CSD, that's something relatively unique to GNU/Linux (and BSD i guess), there are people who hate it, and they should not be excluded, same as people who love it, so on that I base that aprticular choice. From my perspective, the only way not to exclude anyone is to use gtk+, even if it's harder, I mean such GUI application for free drivers (and another good thing, it's for both nvidia and AMD) would be used by people using different DE's, so for such application you have to target them all and not to exclude anyone.

[bridgman]

By the way...
How is the "plumbing" work in MESA going for Radeon Software?
Is the availability of Radeon Software on Linux dependent on the DC/DAL development that is not mainlined yet?
Or does it also have other requirements on the amdgpu side as well?
In short: about how much of the foundations are as of yet missing?

Not sure what you mean by "Radeon Software" here... normally it refers to the entire binary-ish driver stack, which "officially" corresponds to AMDGPU-PRO for Linux although in reality the AMDGPU-PRO stack is really the equivalent of "Radeon Pro Software" and the all-open stack corresponds to "Radeon Software".

We have been using Mesa from the start in AMDGPU-PRO for video encode/decode support, however there are no plans to use it as a replacement for the closed-source GL driver although we do look at that possibility every year or two to see if it makes sense yet.

The AMDGPU-PRO drivers have been shipping with DAL/DC display code from the start, and we have been publishing ~agd5f/*staging* open source trees with DAL/DC included for almost as long. the new display code is not yet upstream but the display team is continuing to work on de-mid-layering it.

I probably didn't answer your question - can you ask again with slightly different words ?

[OneBitUser]

Not sure what you mean by "Radeon Software" here... normally it refers to the entire binary-ish driver stack, which "officially" corresponds to AMDGPU-PRO for Linux although in reality the AMDGPU-PRO stack is really the equivalent of "Radeon Pro Software" and the all-open stack corresponds to "Radeon Software".

We have been using Mesa from the start in AMDGPU-PRO for video encode/decode support, however there are no plans to use it as a replacement for the closed-source GL driver although we do look at that possibility every year or two to see if it makes sense yet.

The AMDGPU-PRO drivers have been shipping with DAL/DC display code from the start, and we have been publishing ~agd5f/*staging* open source trees with DAL/DC included for almost as long. the new display code is not yet upstream but the display team is continuing to work on de-mid-layering it.

I probably didn't answer your question - can you ask again with slightly different words ?

Sorry for not expressing myself clearly!
I was thinking about the Radeon Software - Crimson Edition GUI control center, which, as far as I know, is not yet available even for AMDGPU-PRO users.
There was some talk about releasing it for linux after Radeon Software was introduced on Windows and AMD switched to the hybrid driver development model on linux.
Back then, you said that a lot of "plumbing" had to go into the amdgpu kernel module to enable Crimson's functions.

So... how much of Crimson's requirements are still missing?
Is Crimson only dependent on amdgpu development, or does it require your DC/DAL patches to be mainlined? I know those are included with the PRO driver already, but for my use case, the open drivers are more suitable, and talk was that Crimson might even become available for the open-drivers one day.