Announcement

Collapse
No announcement yet.

AMD Catalyst 9.7 For Linux Released

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by BlackStar View Post
    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 ;-)

    Comment


    • wasn't wine written for nvidia hardware?

      Comment


      • Originally posted by energyman View Post
        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..

        Comment


        • Originally posted by Qaridarium View Post
          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).

          Comment


          • Originally posted by Tares View Post
            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.

            Comment


            • Originally posted by BlackStar View Post
              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.
              Last edited by TrentZ; 07-25-2009, 07:37 PM.

              Comment


              • put main effort on upstream, not distros

                Originally posted by bridgman View Post
                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?

                Comment


                • Originally posted by mariusm View Post
                  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?

                  Comment


                  • Originally posted by mariusm View Post
                    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.

                    Comment


                    • Originally posted by BlackStar View Post
                      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

                      Comment

                      Working...
                      X