AMD Catalyst 9.7 For Linux Released

[Tares]

For the record, 9.8 beta includes a package called xvba (guess what that is ) 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?

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

put main effort on upstream, not distros

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.

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