AMD Catalyst 9.7 For Linux Released

[djdoo]

Reminds me of the bad old days where progress was slower than death...

Nvidia's driver has VDPAU for HD video playback and it can be used even with 2.6.30 kernel...
ATI lags behind again, where the hell is XvBA(HD video playback)?? When will it be usable??
Fedora 11 is one month old now, where is the support to a major Linux distro??

One more thing, nvidia ,which is a hated company to me for many reasons, does never report support to a distro but their newer drivers say support for newer cards, newer Xorg version, newer Kernels, newer OpenGL. In general the key system parts every distro contains RPM style or DEB style..
Guys there in ATI understand something, linux distros are made of common pieces of software and the systems follow a common build structure, you don't need to test each distro separately all the time and report that oh it is ok for openSUSE 11.1 let's say cause like that it will take you a lot of time to test the driver and slow the development process.

Just read what the X new let's say distro contains, Kernel, Xserver key parts generally, install them under one distro and test the driver!! So simple! And also you can develop it faster like that...
We are not Windoze here, 98-NT or Vista other drivers and so on...
Also most of us are not technically newbies and if there are newbies our communities can easily help them understand some basic technical things.

For example I use openSUSE 11.1 which ships with Xserver 1.5.2 but I use Xserver 1.6.2 right now, I just upgraded the packages from a dedicated Xorg repo SUSE has, just a few clicks...

[cutterjohn]

Bug: Freeze on video playback after awake from sleep STILL present. (My R, S, E, I, N, U and B keys are getting worn out...)

(Didn't test freeze on wake when effects enabled bug, but I have a sneaky suspicion that this is still present as well.)

Bug: Catalyst sometimes does NOT restore original desktop resolution when quitting from full screen applications. (Been there ever since I've used catalyst, but I never mentioned it.)

Bug: Virtual consoles' displays are corrupted when the above appears. (ALL VCs. Did NOT try switching to X then back to VC, but restoring original desktop resolution "fixes" this.)

I'd kind of like to see those freeze bugs fixed sometime this century...

[EDIT="out of control"]
Have NOT yet observed the random black rectangle corruption problem yet, but I'm not going to say that that's been fixed yet, although the corruption on X.org/catalyst startup has been fixed. (Used to minorly corrupt the Ubuntu boot progress bar, or at least the colors.)

I've also noticed some strange slightly off shade of color problems in ANY sort of graphic display, primarily pictures/videos but am unsure ATM if this is LCD panel related or not. Needs further investigation.

Bug: AMD needs to seriously poach at least some of the nVidia driver crew...

Semi happy unrelated note: Europa Universalis III + NA + IN & Europa Universalis - Rome + VV work perfectly under wine w/some native(Windows) libs. Guild Wars works if you use the memory patch, although the char selection/creation screen is corrupted, play/load/login screens are fine.

Yet to test: Mount & Blade.

You'd think that this catalyst driver being based on the "pro" driver primarily, would have MUCH better opengl support as that's a primary "feature" of "pro" drivers, or at least I'd hope that it would be...

CEDEGA: WINE seems to have surpassed Cedega several years ago now, or at least I have MUCH better luck in general with wine than I did with Cedega. Cedega was pretty much only useful for a tiny handful of games that Cedega hacked the crap out of their emulation layer to run, of course many of those also ran fine under wine as well.

Monthly releases: grabbing at straws in the 9.6 thread IIRC I suggested dropping the monthly releases in favor of measurable milestones & serious bugfixing, but it was, sort of, explained to me that, that would not help any. I still think that it would, but I don't work for AMD so I've got no clue as to how they kludge together their monthly X driver disasters. I guess that AMD is not really interested in the GPU market after all other than their embedded sales & CPU/GPU kludge. I for one want NO part of shoehorning a GPU into the CPU. It just seems like a bad idea unless you're actually selling CPUs in which case they presumably see a GPU upgrade also requiring a new CPU and more pppprrrrooooffffiiiittttssss.

I observed the same behavior on my computer running a 4850 on ubuntu.
I've seen my Xorg memory usage increase constantly so there might be a memory leak related to FGLRX but I never had the time to investigate more :/.
It started for me with 9.6 catalyst.

But I don't really care anymore, got bored with FGLRX issues... I think I'll switch back to Nvidia
Reply With Quote

I noted a very LONG time ago that my 4850 + catalyst 9.<whateveritwas> + X.org that X.org was using VAST amounts of memory(few 100MB) after a period of a few hours v. my desktop w/7600GT + X.org which was staying fairly stable(after weeks) at around <100MB of memory usage.

Using 150MB resident ATM, and it's creeped up a few 100KB in the last minute or so...

Tell them that they should scrap their driver and see what they say

... but their's actually works pretty well, and supports all sorts of bells & whistles across all supported OSes. Not to mention they don't play games with their windows drivers like AMD does with the generic catalysts.

My "job" here is as the open source guy, but I try to help out with fglrx questions where I can. Everyone should have a hobby

You're a masochist...

Agreed, but Fedora figures are backed up by statistics and methdology (something I don't think any other distro has provided.) Also, keep in mind all those cheap One-Laptop-Per-Child (>1 mill) are running Fedora, as a fair few servers, and it's a favourite at universities.

Servers really shouldn't need ANY video drivers... why waste resources run X on a server? Hell, why even have a GPU in a server? I only do in mine since I recycle my older PCs to serve as servers...

I guess you didn't see the former posts about a leaked 9.8 driver, which corfirms 2.6.30 in the next fglrx official release?

... and I suppose that means that 9.9 will support .31 or Ubuntu gets a special driver again maybe as IIRC they're planning on .31 for 9.10 ...


SUSPEND PROBLEMS: tyr turning off compositing IF you have it enabled. It solved freeze when awaking from sleep for me, but come on lets get this fixed before the next millenia...

...and before I end this frankenpost, I'll re-iterate, the linux catalyst drivers are SUPPOSEDLY based off the workstation drivers, yet they don't support even OpenGL 3.2?! Seems to me that recent OpenGL spec support would be a top priority for a workstation driver... along with opencl and other goodies...
[/EDIT]

[mirv]

...and before I end this frankenpost, I'll re-iterate, the linux catalyst drivers are SUPPOSEDLY based off the workstation drivers, yet they don't support even OpenGL 3.2?! Seems to me that recent OpenGL spec support would be a top priority for a workstation driver... along with opencl and other goodies...
[/EDIT]

What is it with people? Opengl3.2 hasn't even been released yet, so how could they possibly officially support it? And before people quote the nvidia driver at me - again, Opengl3.2 has not been released, so nvidia can not claim to support it. The version number is basically a mistake. And if anyone actually checked, all things likely to be part of Opengl3.2 are already in the latest Catalyst driver.
Do some research next time.

[bridgman]

Hey, you are doing it wrong! don't spread your efforts, but focus: work with upstream vanilla stuff, and then let distro maintainers take care of supporting it in their distribution. If you do this -- just about anyone can replicate your success: distro maintainers as well as a few "power" users (kernel compile is not a rocket science anymore!).

...

Note that I am not telling to drop communication with distros, the communication should be there, but just let them package the stuff themselves.

Marius, we moved distro-specific packaging and support out into a public repo a couple of years ago - what you're talking about is already happening.

When I talk about "supporting more distros" vs "making faster progress" here's a specific example for clarity. Over the last few months we could either have spent time on improving compositing and video playback support or spent that time supporting newer kernels. We went with the first option, since that gives a *better* experience to a broad range of Linux users, but not to users of *all* distros yet.

You say we should focus, and this is how we focus. I understand that you would prefer us to make a different choice, ie to spend time on new kernel support rather than spending that time on, say, improving video playback or operation under Wine. Each quarter the choices get a bit easier, and at some point in the future I imagine that tradeoff will become a non-issue.

djdoo, I know that every distro has a kernel and an X server, but the variations between distros can be huge because of distro-specific patch sets. Fedora runs up to six months ahead of upstream at times (the F10 graphics changes are only getting into upstream in the last month) so different distros will often have *very* different behaviour and require that a significant chunk of the testing (and bug fixing) be repeated for each distro. There are obviously distros which use similar component versions, and we already clump them together for testing and fixing.

Cutterjohn, the workstation market doesn't look so much for bleeding edge OpenGL features as it does performance and stability on existing software applications, often a few years old or more. Support for new OpenGL features is primarily for major app developers, but we normally have a direct devrel relationship with them and our driver engineers work directly with their devs on new features.

[Joe Sixpack]

For those of you who are saying that people just need to STFU and quit complaining maybe you should take your own advice. Some people do have unreasonable expectations, however I haven't seen a lot of unreasonable expectations in this thread.

The term "unreasonable expectations" is completely subjective. As far as the complaining - well it's not what you say but how you say it. Yes complaining is your right, but to say "going with ATI was the worst decision of my life" or implying that the entire AMD team is completely incompetent is a bit of an overkill.

[blindfrog]

OK, help me here. We don't claim to support Fedora, and we recommend the open source drivers for Fedora (which RH agrees with). How can we have a "Catalyst disaster" with Fedora ?

Yeah we know Fedora is cutting edge but why does your competitors drivers have no trouble with it? They work even with rawhide. It doesn't feel like good enough excuse. Maybe AMD should start replacing bigger parts of X like nvidia does, because frankly it seems like a lot better way. I mean it's proprietary blob anyway and people who install it realizes that (hopefully) so who cares how invasive it is as long as it works?

Especially because free driver is going to take at least a year before it's anywhere near the catalyst drivers functionality and performance. All this waiting and these odd reasons for waiting are just frustrating. When nvidias drivers just works everywhere why would anyone bother with AMD clearly more unreliable offering. Doesn't make any sense.

Other than that thanks and it's great that you are here answering to our silly questions. Very good PR!

[mirv]

I think ati are going to start replacing bits of x (I'm pretty sure I read that somewhere, or is my sleep-deprived brain making things up again?) - I'll look for the quote somewhere. But I personally prefer the drivers to "invade" as little as possible.

[nanonyme]

nononono..LOOL... on my system "glxinfo"

OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon HD 4600 Series
OpenGL version string: 2.1.8975
OpenGL shading language version string: 1.40


GSGL 1.4 = openGL3.1!!!!!!!!!!!!!!!!!!!!!!!!!

I seriously recommend sleeping it off, whatever it is you're taking.

[bridgman]

Yeah we know Fedora is cutting edge but why does your competitors drivers have no trouble with it? They work even with rawhide. It doesn't feel like good enough excuse. Maybe AMD should start replacing bigger parts of X like nvidia does, because frankly it seems like a lot better way. I mean it's proprietary blob anyway and people who install it realizes that (hopefully) so who cares how invasive it is as long as it works?

I really have answered this question a dozen or more times already, but let's go for lucky thirteen. Some of our competitors started supporting consumer users and distros several years ago, and today users of those products have forgotten all the problems and the the frustration they went through at the time.

Now it's our turn - we can either keep working at it or give up, whichever you prefer, but anyone who thinks it's possible to wave a magic wand over millions of lines of driver code (and yes, it does take millions of lines of code to implement a state-of-the-art driver these days) and transform it in a few months is dreaming.

I know it was comforting a couple of years ago to think that a handful of open source developers could write a better and faster driver in a few weeks if only they had specs, but I think everyone knows better today (the developers knew what to expect, but nobody asked them ).

The fglrx driver is seeing a lot of improvements, and along the way we need to make decisions about where to focus our efforts. Focusing on improving the core driver rather than extending support for new kernels definitely makes for some unhappy users, but if we changed the decision (say to favor new kernel/distro support over improving composite, video and Wine support) we would simply make a *different* (and larger) group of people unhappy.

Once we finish adding and stabilizing consumer features we probably will not need to make those difficult decisions, but we're not there yet.

Especially because free driver is going to take at least a year before it's anywhere near the catalyst drivers functionality and performance. All this waiting and these odd reasons for waiting are just frustrating. When nvidias drivers just works everywhere why would anyone bother with AMD clearly more unreliable offering. Doesn't make any sense.

By "odd reasons for waiting" do you mean "making our top priority improving the core driver functionality rather than making the driver work on more kernel versions and more distros" ? If you're using a faster-moving distro you might not like that decision but I wouldn't call it odd

There are all kinds of reasons for choosing one product over another. In the specific case of Linux, it might be a preference for open source drivers, or you might be a professional workstation user, or you might be using one of the distros where our support is already pretty solid, or you may be dual-booting with another OS... everyone has to make their own choice. I'm not trying to inflate what we have to offer, but I also think we have come a long way in the last couple of years and we're not done yet.

[djdoo]

Wow guys the conversation really caught fire!!

Well to chill out things a bit and from a more cold blooded let's say point of view we must put the facts into a correct order and weight them.
From the day the new coded fglrx driver arrived for us the long waited costumers for a modern linux graphics driver we have seen only improvements and big ones! The fact that we compare 3D and 2D performance today with the years more prepared nvidia driver and in many parts fglrx outperforms the nvidia or even the windows catalyst driver is the proof that the dedicated developers are really working on it!
Does anyone of you remember how awful was the old codebase fglrx was?? Most of the times it couldn't even install itself!!

@bridgman:
Listen my friend John, I understand that your team has a lot of work to do finetuning and rounding the sharp edges of the code and I known that in anything any work you do in life settings and finetunings require most of your working time and most of the testing but your team's greatest problem isn't us still complaining or time that is not enough or economic crisis let's say, it is still the ghost of the old codebase fglrx driver which was almost abandoned for long long time... Consider how much time was lost all those years for development and the mistake in ATI's policy not to see that linux will be growing pretty fast the forecoming years and take an important piece of the PC market cake always growing in fast rates and so important to make Microsoft write opensource drivers(Hyper-V) for Linux!!
And now you always have to run sprints to catch the development stream whereas nvidia still has a slow steady tempo over the years...

I have a preposition also, if we can do something to help there? Not in coding but in testing or writing-translating documentation for the driver make things more friendly for new linux friends anything that could make the developers have less questions in their minds and increase the number of answers...

Well for the history Fedora 11 does not even use an xorg.conf file...