Red Hat Joins Khronos, The Group Behind OpenGL & Vulkan

[SystemCrasher]

I still maintain to this day that atombios is part of a culture of abstracting badly and hiding things in black boxes, and it is that culture that led to the bad name of fglrx/catalyst, therefor atombios is a part of why fglrx was/is that hated.

Oh, can one of long term fglrx haters have a voice in this epic thread?

I hate fglrx mostly because:
1) Its kernel side is not a part of kernel. So system often fells apart on any major upgrade. Any serious uplift of kernel, and you're screwed. And it is so cool to recover system from black screen where nothing works, because it has been graphic driver, dammit.
2) For same reason it is extremely hostile to running recent software components. Generally, if one uses fglrx, he/she can't give a try to early techs and report bugs before these bugs would land some long term releases and so on. Then it ensures months or even years of pain in the rear, here and there. It suxx.
3) Catalyst was almost never able to build deb pkg properly. Then it also fails to remove from system without leftovers.
4) It had shitload of stability issues. Involving nasty kernel lockups after some days or weeks of running. So on my hardware I rarely seen uptime exceeding a week. And it's not like if it's cool to be knocked out of my machine due to GPU driver causing kernel-side GPF, where I only have option press "any key", as long as this key reboots my machine.
5) It's not like if catalyst development is very public. Nor it haves real bug tracker. So it takes a lot of efforts to get idea where to report bug and then there is nearly no feedback in it usual expected form. And nobody likes idea to write bug reports to /dev/null.
6) To make things more funny, Linux kernel devs would not deal with tainted kernels, very clearly stating that if you're using proprietary kernel module, you're on your own at this point. Basically if one runs fglrx, they're completely out of kernel dev efforts, even bug reporting is not an option. Basically you're doomed to live with nasty bugs forever and complete OS lockups due to kernel GPS aren't something I can tolerate.
7) Fglrx is not really plug-n-play. So you can't have decent desktop experience in liveCD, etc. And "go download 3rd party crap, run setup.exe, reboot, blabla" sounds like some ancient story from MS-DOS ages.
8) It also sucked in 2D speed.
9) And it wasn't really integrated with system. AFAIK, KDB can't use it to draw itself when most of kernel is stalled. It even can't display kernel panic data on screen. Kernel panic it has caused, itself. That's what I really call "fucking shame" for GPU drivers.
10) No fancy consoles in native screen resolution with fglrx. Seriously, 80x25 sucks, especially on 2560x1600 screen. Let this ancient shit to die and do not ever dare to show me this DOS-aged horror crap again.

So, this is not all about AtomBIOS. Even if I can understand your idea that direct hardware programming could be cleaner way than getting some (interpreted) VBIOS blob on your way, I do think major fglrx disadvantages aren't directly related to AtomBIOS. And as you can see, AMD finally got idea proprietary out of tree kernel module suxx. That's what is going to fix most of real-world Catalyst woes. Sure, there is always more room for improvement. But from what I remember, Radeon power management sucked a lot before being reworked as ... more or less what Catalyst did. So DPM appeared and from user's standpoint it works great. And much better than older solutions do (not like if I can do fair comparison though ... because RadeonHD does not supports recent GPUs).

[drSeehas]

fglrx/catalyst was the reason why I bought only one AMD card in a looong time. NVIDIA got the money instead.
But it seems the AMD open source driver will be competitive (to closed source NVIDIA) in the future.

[nanonyme]

I'm personally looking for an upgrade for my old AMD card but seems there aren't yet that many VI cards with DP 1.2a support. Getting a new card Right Now appears to mean risking missing FreeSync

[airlied]

Your supposed lack of knowledge of that proposal (which i find very very hard to believe), is still not enough a reason to have so actively supported a fork of the RadeonHD code, which produced a driver which was less technically advanced and less free than RadeonHD. The competing driver did everything the ATI way, from PLL calculation, to I2C, to HPD, to atombios, even powermanagement took well into this decade.

The fact that the SuSE account manager at AMD was moved aside in.. September 2007? And was replaced with the account manager for Red Hat, that was a marked shift in the relationship between AMD and SuSE. It also seriously hints at Redhat not being happy with not being able to catch the glory on RadeonHD, and that it threatened to damage the AMD/Red hat relationship and make things worse for AMD servers. That explains a lot more of the actions taken by a lot of people than "i claim i didn't know about your proposal".

Red Hat never gave a shit about glory for developing radeonhd, we don't do one-off engineering generally unless it has a large payback, and any one-off engineering is generally done by a specialist group not by our main development teams.

I know you love to live the conspiracy and all that, but Red Hat as a company, and even the little group of people in my group at Red Hat really didn't give a shit about relationships between AMD and RH at a business level. Most of my involvement with developing -ati was contact with John and Alex not in formal AMD/RH meetings or talks, I don't even know if we had formal AMD/RH meetings or talks, but I never went to any or know of anyone where this was a thing that got mentioned. I'm sorry you don't believe how much latitude I get in Red Hat to work on what I want, without business drivers or funding from other companies, I'm surprised myself some times how much leeway I have, so I don't expect anyone who doesn't work here to ever understand it.

You constantly explain things by the actions of shadowy figures acting against you, there is a medical definition for this and I believe medication can also help.

Dave.