AMD Catalyst 9.7 For Linux Released

[Tares]

For the record, 9.8 beta includes a package called xvba (guess what that is :p) and seems to improve video and 3d performance. Still no VSync on OpenGL 3 contexts, despite the introduction of GLX_SGI_swap_control.


This package is not new. It's there since 9.1 ? or even ealier. I don't remember.

As for the driver I'll test it later tonight, but i personally think that since fglrx was stripped of older hardware it needs a rewrite... from the start. I know it sounds bad and unrealistic, but I believe then the driver would finally be a nice peace of code.

ow yeah, if that would happen... I wouldn't mind waiting for the driver like a half of year, with no middle releases ;-)

[energyman]

wasn't wine written for nvidia hardware?

[Qaridarium]

wasn't wine written for nvidia hardware?

Today nvdia have more wine dev's and amd need's OpenGL3.2 to have the same good standing at the wine side of live yes.

Today its simple amd/ati works on wine but nvidia works better if openGL3.2 was in the driver wine can use the same code for nvidia and amd.

in fakt wine devs don't want be nvidia only..

[BlackStar]

Today its simple amd/ati works on wine but nvidia works better if openGL3.2 was in the driver wine can use the same code for nvidia and amd.

OpenGL 3.2 is not released. A status update is expected in the OpenGL BOF at Siggraph, on Wednesday 5 August.

Ati drivers support OpenGL 3.0 and I seriously doubt Wine is using anything from OpenGL 3.1 (and only a handful of features from 3.0 at best).

[BlackStar]

This package is not new. It's there since 9.1 ? or even ealier. I don't remember.

As for the driver I'll test it later tonight, but i personally think that since fglrx was stripped of older hardware it needs a rewrite... from the start. I know it sounds bad and unrealistic, but I believe then the driver would finally be a nice peace of code.

ow yeah, if that would happen... I wouldn't mind waiting for the driver like a half of year, with no middle releases ;-)

Maybe that's so, but my 9.7 packages (--buildpkg Ubuntu/Jaunty) did not have this file.

[TrentZ]

Maybe that's so, but my 9.7 packages (--buildpkg Ubuntu/Jaunty) did not have this file.

Indeed, it is there (9.7 and earlier), but

This package provides the support for the AMD unified video decoder library. This can be used for accelerated XvMC output.

Unfortunately, this package requires an unsupported library, so it is not installed by default.

http://packages.ubuntu.com/jaunty/libamdxvba1

You can find the library that this deb provides inside the official package*, at arch/x86/usr/X11R6/lib/libAMDXvBA.so.1.0 (x86) or /arch/x86_64/usr/X11R6/lib64/libAMDXvBA.so.1.0 (x86_64).

* I'm referring to 9.7.

[mariusm]

The choice is pretty simple -- we can spread our efforts out and attemt to support all distros equally but make slower progress overall, or focus on a representative subset of distros and make progress more quickly, *then* focus on improving / speeding up support for the rest. The first approach means our overall quality of Linux support will be lower but we won't piss anyone off; the second approach means we can offer a good Linux user experience more quickly but will some distro users will feel insulted by our choices.


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!).

I appreciate your installer feature to be able to generate Debian/unstable debs, but in case of 2.6.29/30 it's worthless and sometimes it takes months for Debian maintainers to figure how to patch this stuff to include into distribution. Also the release information confusion of not being able to support 4month old kernel stretches into distros too (distros take newer kernels into distributions and fglrx users get caught up in the middle of this transition, waste their time, revert and simply dump ATI, distro or Linux altogether).

I am not a Debian developer, just a user, but IMHO such direct "distro support" is a waste of everyone's resources.
Note that I am not telling to drop communication with distros, the communication should be there, but just let them package the stuff themselves.

AFAIK, ATI has been told numerous times for years now: work with kernel developers. It has probably happened with radeon/radeonhd driver, but WTF is wrong with fglrx?

[kensai]

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!).
Yeah, the users have been able to see that AMD devs are doing it all wrong, and present very weak logics to why they are doing it that way. But, see they want to defend their ignorance month by month. If you connect every post bridgman has been writing for some time now, all summarizes to this: the incomplete oss drivers are going to get a bit better, but catalyst will only become for CAD customers, thus being an outdated blob with support for only 3 outdated distros. So they panorama is not looking very well. But has it ever for AMD/ATI?

[mirv]

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!).

I appreciate your installer feature to be able to generate Debian/unstable debs, but in case of 2.6.29/30 it's worthless and sometimes it takes months for Debian maintainers to figure how to patch this stuff to include into distribution. Also the release information confusion of not being able to support 4month old kernel stretches into distros too (distros take newer kernels into distributions and fglrx users get caught up in the middle of this transition, waste their time, revert and simply dump ATI, distro or Linux altogether).

I am not a Debian developer, just a user, but IMHO such direct "distro support" is a waste of everyone's resources.
Note that I am not telling to drop communication with distros, the communication should be there, but just let them package the stuff themselves.

AFAIK, ATI has been told numerous times for years now: work with kernel developers. It has probably happened with radeon/radeonhd driver, but WTF is wrong with fglrx?

ATI use the fglrx drivers primarily for workstation support - secondary for home user. This has been mentioned on many occasions. And those workstation users require a certain level of support from the drivers with whatever distro they use - and that's why they are supporting distros rather than vanilla stuff. They go where the money is, and that's not with purely vanilla and leaving the distros to take care of it themselves.
I would point out that the distros aren't there for the workstations, but the workstations may use them. And as such, graphics support comes down to ATI/AMD, not the distro.

[Qaridarium]

OpenGL 3.2 is not released. A status update is expected in the OpenGL BOF at Siggraph, on Wednesday 5 August.

Ati drivers support OpenGL 3.0 and I seriously doubt Wine is using anything from OpenGL 3.1 (and only a handful of features from 3.0 at best).

catalyst supports opengl3.1....

WINE NEED OpenGL3.2!!!!!!!

on nvidia side there have OpenGL3.2 like nvidia only extansions..

this key feature will have the ati carts first @ openGL°3.2

[Dark_Star]

I heard they came up with new user interface for Vista and win7 .. Any screenshot for the same ?

Linux interface will get revamped in upcoming release, hopefully :| and seeing they improvement track don't expect too much ..

[TrentZ]

catalyst supports opengl3.1....

No.

WINE NEED OpenGL3.2!!!!!!!

No.

[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...


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 QuoteI 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 hobbyYou'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...

[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.

[Qaridarium]

No.



No.

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!!!!!!!!!!!!!!!!!!!!!!!!!

[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 :D

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!!:D

@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...

[nanonyme]

so important to make Microsoft write opensource drivers(Hyper-V) for Linux!!;)Wasn't the point of the driver that you will be able to run a Windows (tm) operating system on top of Linux kernel's virtualization layer fast?
Well for the history Fedora 11 does not even use an xorg.conf file... It can use one, it just doesn't by default come with one since opensource drivers are autodetected and usually come with reasonable default settings.

[bridgman]

Wasn't the point of the driver that you will be able to run a Windows (tm) operating system on top of Linux kernel's virtualization layer fast?

I thought it was the other way round - improving performance when Windows was the host OS (ie running all the time) and Linux was running on top (when needed).

[djdoo]

It can use one, it just doesn't by default come with one since opensource drivers are autodetected and usually come with reasonable default settings.

Well the thing I know for opensource drivers is that they can use the 40% to say the most of your HD 2xxx or 3xxx or 4xxx card's abilities wereas fglrx currently utilizes almost 80% for me correctly...

They are still not ready for the modern cards even though they are more user friendly(no installation, automatic output detection and 2D acceptable usability) because think about the reasons you buy a new graphics card or a motherboard with a modern integrated one...

1. 3D performance on much higher resolutions new monitors have and new game titles.
2. HD Video playback and modern 2D features.
3. Combination of more GPUs -> Crossfire.
4. More than one screens.
5. Better power management.

Opensource drivers cover now only a part of the 2. reason and a part of the 4. too. 1-3-5 are of no discussion out of their abilities yet...
We will hopefully see improvements as Gallium 3D matures but for now nothing exciting for us...;)

[Qaridarium]

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

realy.. what is your problem?

if you do not belive that wine have an wine specific OpenGL exansion in openGL3.2 tell this as an question to bridgman!

this extansion will make the transcode from dx to openGL much faster and modern features at the first time realy playaple..

becourse all the time you can handel all DX in an Software Rendericer.. but its not fast wine can't support games with slow Pur GSGL code.

the new exansion in openGL3.2... in wine 1.1.24 and up wine has code for invidia with this technologie to speeds up the transcode.

in wine 1.1.25 AMD/ATI works but only GSGL "slow" becourse to much overhead to controll the transcode.

OpenGL3.2 will speed up wine!

[smitty3268]

realy.. what is your problem?

if you do not belive that wine have an wine specific OpenGL exansion in openGL3.2 tell this as an question to bridgman!

this extansion will make the transcode from dx to openGL much faster and modern features at the first time realy playaple..

becourse all the time you can handel all DX in an Software Rendericer.. but its not fast wine can't support games with slow Pur GSGL code.

the new exansion in openGL3.2... in wine 1.1.24 and up wine has code for invidia with this technologie to speeds up the transcode.

in wine 1.1.25 AMD/ATI works but only GSGL "slow" becourse to much overhead to controll the transcode.

OpenGL3.2 will speed up wine!

Qaridarium, it's self-evident that wine doesn't have some requirement on OpenGL3.2. Why is that, you ask? BECAUSE OGL3.2 DOESN'T EXIST YET!!! And unless you work for Khronos, or one of the parties involved in creating the new standard, you really have no clue about what's going to be made a part of 3.2. Now maybe the nvidia extension you're talking about will be added, but you don't know that for sure. OGL3.2 could come out without it, and it would still just be a proprietary nvidia extension, and then I suppose you'd probably be coming here talking about how wine requires OpenGL 3.3.

[Dimarchi]

Gradual improvement. For the first time I can watch movies with Compiz on and not having the computer lock on me now and then. I still notice tearing, occasionally, with default settings...haven't yet tried others. Using Ubuntu 9.04 (64-bit), video card Gigabyte's 1gb 4870 connected to a Benq 24 inch LCD monitor with DVI - I have yet to use --buildpkg. The desktop is extended to include my analog TV using Display.

Catalyst reports my main monitor's max res the same as TV's res (1024x768). Set to correct res of 1920x1200 with Display. It also reports the LCD monitor as Display 2 - probably due to the way these monitors are connected (as specified in Gigabyte's manual). This is true in Vista, as well. The main effect in my daily use is that Firefox opens up to the vertically maxed res of 768 instead of 1200 (apparently), so that I have to stretch Firefox's window downwards. This used to be the case with Thunderbird, too, but it opens up correctly with this driver.

[Wintervenom]

..........
Really, what is your problem?

If you do not believe that Wine has a Wine-specific OpenGL 3.2 extension, ask Bridgman!

This extension will make the DirectX-to-OpenGL translation much faster.

You can handle DirectX calls with software rendering, but its slow, and Wine can't support games with slow pure GSGL code.

The new OpenGL 3.2 extension in Wine 1.1.24 and up has code for nVidia with this technology that speeds up the translation.

In Wine 1.1.25, AMD/ATi works, but GSGL is slow because there is too much overhead in the translation.

OpenGL 3.2 will speed up Wine!

[Heiko]

No.



No.

I tried creating an OpenGL 3.1 context in a self written OpenGL program. This fails with Catalyst 9.6 (an OpenGL error occurs), but with Catalyst 9.7 it doesn't and glGetString(GL_VERSION) and glGetString(GL_SHADING_LANGUAGE_VERSION) returns the following:

glGetString(GL_VERSION): 3.1.8787 BETA Forward-Compatible Context
glGetString(GL_SHADING_LANGUAGE_VERSION): 1.30

So... Catalyst 9.7 has beta 3.1 support, but no support for GLSL 1.40, or it just shows the wrong version number for glsl (that happened when OpenGL 3.0 support was introduced as well, I didn't try creating a glsl program with the 1.40 version string, so it might actually support it...).

I didn't check whether all OpenGL 3.1 features were available, just reporting that creating a 3.1 context works and that it reports in the version string to be a 3.1 context.

[PuckPoltergeist]

I tried creating an OpenGL 3.1 context in a self written OpenGL program. This fails with Catalyst 9.6 (an OpenGL error occurs), but with Catalyst 9.7 it doesn't and glGetString(GL_VERSION) and glGetString(GL_SHADING_LANGUAGE_VERSION) returns the following:

glGetString(GL_VERSION): 3.1.8787 BETA Forward-Compatible Context
glGetString(GL_SHADING_LANGUAGE_VERSION): 1.30

So... Catalyst 9.7 has beta 3.1 support, but no support for GLSL 1.40, or it just shows the wrong version number for glsl (that happened when OpenGL 3.0 support was introduced as well, I didn't try creating a glsl program with the 1.40 version string, so it might actually support it...).

I didn't check whether all OpenGL 3.1 features were available, just reporting that creating a 3.1 context works and that it reports in the version string to be a 3.1 context.

The version string indicates OGL 3.2 Beta not 3.1. If it would be 3.1 the string should be something like 3.0.xxxx.

[Qaridarium]

I tried creating an OpenGL 3.1 context in a self written OpenGL program. This fails with Catalyst 9.6 (an OpenGL error occurs), but with Catalyst 9.7 it doesn't and glGetString(GL_VERSION) and glGetString(GL_SHADING_LANGUAGE_VERSION) returns the following:

glGetString(GL_VERSION): 3.1.8787 BETA Forward-Compatible Context
glGetString(GL_SHADING_LANGUAGE_VERSION): 1.30

So... Catalyst 9.7 has beta 3.1 support, but no support for GLSL 1.40, or it just shows the wrong version number for glsl (that happened when OpenGL 3.0 support was introduced as well, I didn't try creating a glsl program with the 1.40 version string, so it might actually support it...).

I didn't check whether all OpenGL 3.1 features were available, just reporting that creating a 3.1 context works and that it reports in the version string to be a 3.1 context.

"or it just shows the wrong version number"

only wrong version number! 9-8 fix this problem.

[Qaridarium]

The version string indicates OGL 3.2 Beta not 3.1. If it would be 3.1 the string should be something like 3.0.xxxx.

yes 3.2 :-) wine specific openGL extansion is coming!

[Qaridarium]

Qaridarium, it's self-evident that wine doesn't have some requirement on OpenGL3.2. Why is that, you ask? BECAUSE OGL3.2 DOESN'T EXIST YET!!! And unless you work for Khronos, or one of the parties involved in creating the new standard, you really have no clue about what's going to be made a part of 3.2. Now maybe the nvidia extension you're talking about will be added, but you don't know that for sure. OGL3.2 could come out without it, and it would still just be a proprietary nvidia extension, and then I suppose you'd probably be coming here talking about how wine requires OpenGL 3.3.

realy... nvidia has openGL3.2 beta driver... with wine specific openGL extansion..

amd has OpenGL3.2 beta drivers to with wine specific openGL extansion..

the only lithle point is.. wine 1.1.25 already has nvidia-only exansion it it..

wine 1.1.27 will chance this point into an openGL3.2 extansion

[NeoBrain]

realy... nvidia has openGL3.2 beta driver... with wine specific openGL extansion..

amd has OpenGL3.2 beta drivers to with wine specific openGL extansion..

the only lithle point is.. wine 1.1.25 already has nvidia-only exansion it it..

wine 1.1.27 will chance this point into an openGL3.2 extansion

Now please, would you be so kind and at least take a moment to re-read what you're writing? It's okay if English is not your native language etc, but you don't even seem to try to write something which others can understand. Anyways, it can't be that hard to write "extension" correctly, especially since someone already corrected you in that regard, can it?

So... I could hazard some guesses about what you mean, but I don't really have a clue what you're trying to tell us (didn't read the whole thread on the other hand).

[Heiko]

The version string indicates OGL 3.2 Beta not 3.1. If it would be 3.1 the string should be something like 3.0.xxxx.

How do you translate `3.1.8787 BETA' into an OpenGL 3.2 beta? It clearly shows 3.1 in the version string, not 3.2. In fact, I tried creating an OpenGL 3.2 context (of course I wanted to try and see whether it worked), but that gave an OpenGL error. So catalyst 9.7 clearly has NO OGL 3.2 support.

Catalyst 9.6 showed as version string (after requesting an OpenGL 3.0 context) something like: 3.0.xxxx. Really... 3.0.xxxx means OpenGL 3.0 and 3.1.xxxx means OpenGL 3.1 not OpenGL 3.2 (which will be something like 3.2.xxxx).

[PuckPoltergeist]

How do you translate `3.1.8787 BETA' into an OpenGL 3.2 beta? It clearly shows 3.1 in the version string, not 3.2. In fact, I tried creating an OpenGL 3.2 context (of course I wanted to try and see whether it worked), but that gave an OpenGL error. So catalyst 9.7 clearly has NO OGL 3.2 support.

Catalyst 9.6 showed as version string (after requesting an OpenGL 3.0 context) something like: 3.0.xxxx. Really... 3.0.xxxx means OpenGL 3.0 and 3.1.xxxx means OpenGL 3.1 not OpenGL 3.2 (which will be something like 3.2.xxxx).

3.0.xxxx something shortly before 3.1
3.1.xxxx something shortly before 3.2

[Heiko]

3.0.xxxx something shortly before 3.1
3.1.xxxx something shortly before 3.2

I don't think I understand what you mean and want to say.

What I did is make an application that does the following:

Create an OpenGL 3.0 context, then ask OpenGL which version it is. It says: `OpenGL 3.0.xxxx'. So I ask for OpenGL 3.0 and I got OpenGL 3.0. Then I tried creating an OpenGL 3.1 context and thereafter I asked OpenGL which version it is. It says: `OpenGL 3.1.xxxx beta'. So I asked for OpenGL 3.1 and I got a beta OpenGL 3.1 context. The last thing I tried was creating an OpenGL 3.2 context. This does not work, OpenGL gave an error.

So why do you claim Catalyst 9.7 supports OpenGL 3.2? Because it clearly doesn't.


OpenGL reference pages say the following:

The GL_VERSION and GL_SHADING_LANGUAGE_VERSION strings begin with a version number.
The version number uses one of these forms:

major_number.minor_number
major_number.minor_number.release_number


In this case it says 3.1.8787.

3: major version (OpenGL 3.x)
1: minor version (OpenGL 3.1)
8787: release_number: just a number AMD uses to indicate which version of the OpenGL driver this is. It increases with every release. It has nothing to do with OpenGL itself.

[PuckPoltergeist]

OpenGL reference pages say the following:

The GL_VERSION and GL_SHADING_LANGUAGE_VERSION strings begin with a version number.
The version number uses one of these forms:

major_number.minor_number
major_number.minor_number.release_number


In this case it says 3.1.8787.

3: major version (OpenGL 3.x)
1: minor version (OpenGL 3.1)
8787: release_number: just a number AMD uses to indicate which version of the OpenGL driver this is. It increases with every release. It has nothing to do with OpenGL itself.
Ok, then I was wrong. I took the third number into the OGL versioning scheme, like the KDE versioning scheme. Didn't know that the third number is unreleated to the OGL version.

[Qaridarium]

Now please, would you be so kind and at least take a moment to re-read what you're writing? It's okay if English is not your native language etc, but you don't even seem to try to write something which others can understand. Anyways, it can't be that hard to write "extension" correctly, especially since someone already corrected you in that regard, can it?

So... I could hazard some guesses about what you mean, but I don't really have a clue what you're trying to tell us (didn't read the whole thread on the other hand).

i'm realy sorry "extension" an E in spoken english is like a spoken german A

Extension=Ausdehnung oder Erweiterung

i realy try to learn this word :)

[Qaridarium]

Ok, then I was wrong. I took the third number into the OGL versioning scheme, like the KDE versioning scheme. Didn't know that the third number is unreleated to the OGL version.

the point is.. the version number in the driver abaut openGL is not the feature set of REAL features of the driver!

in 9-7 the GSGL string is wrong 1.3... in the beta its korrekt 1.4!

gsgl1.4=OpenGL3.1

in fakt nvidia has openGL3.2 beta... in fakt amd work on 3.2 right now!

[Kano]

Did you notice that 190.16 reported OpenGL 3.2, then this driver was completely removed from the servers and 190.18 reports now 3.1 ;) Maybe too early *g*

[Heiko]

Did you notice that 190.16 reported OpenGL 3.2, then this driver was completely removed from the servers and 190.18 reports now 3.1 ;) Maybe too early *g*

I thought nvidias 190.18 still reported OpenGL 3.2:
http://www.phoronix.com/scan.php?page=news_item&px=NzQwNg

[Kano]

Look at a benchmark I uploaded:

http://global.phoronix-test-suite.com/?k=profile&u=kano-20279-12391-32594

[cutterjohn]

Bug: Random areas of black rectangles still appear with 9.7. No known way to reproduce but screen refresh clears corruption. Pretty sure it appears even BEFORE putting system to sleep.

[octapult]

Crossfire finally works on my 4870x2 :)
Unigine Tropics got a 10 FPS increase.

I got some error messages in dmesg though:

[ 2911.922373] [fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_open] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0x7f80d3652000,handle:0xd0000000
[ 2912.198467] [fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_open] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0x7f80d2cc5000,handle:0xd1068000
.....


Gentoo Linux with kernel 2.6.30-r4
ATI Catalyst 9.7 (fglrx 8.63.2)
xorg-server 1.6.2.901

[Wintervenom]

See http://bbs.archlinux.org/viewtopic.php?pid=571625#p571625. It's not a fix for the problem itself, but will keep your kernel logs from being spammed with these messages.