Announcement

Collapse
No announcement yet.

Early AMD Catalyst 12.3 Linux Drivers Seep Out

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

  • #11
    Originally posted by adrenochrome View Post
    traditional http://support.amd.com/us/gpudownloa...ded_linux.aspx is not official enough ?
    That looks like an embedded driver build rather than a regular Catalyst (consumer 2-ID) build, so it's going to be configured and tested for embedded SKUs.

    Not sure which driver sacridex is referring to, but there's a decent chance that the embedded driver would show watermarks on consumer SKUs.
    Test signature

    Comment


    • #12
      Originally posted by DaemonFC View Post
      Can you ask someone to look into the DPMS issue where it doesn't resume monitors from sleep mode and quits responding to the keyboard? I've ran into so many people with that problem that I know it has to be wide spread. Is there any QA that goes into FGLRX besides referring to Lindows and XFree86 and calling Linux "like DOS"? It just seems that if I run into things like this after 5 minutes, then you'd think someone at AMD would as well.
      To be fair I never ran into that bug with my measly HD4200, but another Atom netbook I have was having that exact same problem. Maybe it's not a fglrx problem directly?

      Comment


      • #13
        What is wrong with AMD?

        What is wrong with AMD? Why it always sucks?
        Nvidia's current driver's size is 34MB AMD Catalyst for Linux: 100MB
        -Nvidia: complete video acceleration for MPEG-1, MPEG-2, MPEG-4 Part 2 (a.k.a MPEG-4 ASP), VC-1/WMV9 and H.264) 4K resolution / QFHD video decoding at up to 3840 x 2160 pixels, including MVC (Multiview Video Coding H.264 decoding support for Blu-ray 3D and other Full HD 3D at 1080p: vdpau which since beginning works great and in every player.

        AMD: created XvBA with simple MPEG-2, H.264 and VC-1. None player uses this so XvBA is useless which means it could not exist at all. And do not tell me about wrapper to vaapi because I can have intel gpu for free with direct support for vaapi. So why complicating life with wrapper?

        KDE compositing: OpenGL 3 (that?s for us only the NVIDIA blob at the moment, fglrx is only usable with OpenGL 1.x in the composited case which will be dropped in next release)

        AMD still lags behind X org releases for months if not years. Nvidia and Intel on time or even some time before.

        2D: Nvidia stable, no major bugs, full X-Render acceleration. AMD x-video tearing, no X-render.

        What AMD put in this 100MB driver if it is so limited and underdeveloped? Why people still buy Radeons if they are so crappy? You can get Intel with more capabilities and stability for free and Nvidia with much more features for some money more.
        -

        Comment


        • #14
          I'm an AMD fan since the golden Athlon days, but I have to agree with zbiggy on his assessment. On top of all those points I'd still like to add that the quality of the desktop experience is much worse with Radeons than it is either with Intel or nVidia gpus. In fact, the composited desktop experience (smoothness, responsiveness, number of rendering bugs) with Radeons is similar or worse to what you get on a measly 1st gen Atom netbook with it's crappy GMA950 gpu. This is when using either open source drivers or fglrx.

          Comment


          • #15
            Originally posted by devius View Post
            In fact, the composited desktop experience (smoothness, responsiveness, number of rendering bugs) with Radeons is similar or worse to what you get on a measly 1st gen Atom netbook with it's crappy GMA950 gpu. This is when using either open source drivers or fglrx.
            That's funny because my lowly RadeonHD 4550 runs Compiz or Kwin smoothly with open-source drivers..

            AMD: created XvBA with simple MPEG-2, H.264 and VC-1. No player uses this so XvBA is useless which means it could not exist at all.
            It took a while, but xbmc finally makes use of libxvba, and the open-source drivers are working towards shader-based acceleration (and possibly using UVD).

            What does AMD put in this 100MB driver?
            Probably a lot of app-specific optimizations that carried over from Windows.

            Comment


            • #16
              Originally posted by devius View Post
              I'm an AMD fan since the golden Athlon days, but I have to agree with zbiggy on his assessment. On top of all those points I'd still like to add that the quality of the desktop experience is much worse with Radeons than it is either with Intel or nVidia gpus. In fact, the composited desktop experience (smoothness, responsiveness, number of rendering bugs) with Radeons is similar or worse to what you get on a measly 1st gen Atom netbook with it's crappy GMA950 gpu. This is when using either open source drivers or fglrx.
              I can't spill the beans, but I have to urge you to wait a month before making your final determination on Catalyst.... something extremely interesting may or may not be in testing right now.

              Comment


              • #17
                @DanL We talk here about Catalyst for Linux. Not open source driver. With Catalyst OpenGL2 is not available when compositing is on according to KDE developer's blog who is responsible for graphics.

                xvba: xbmc is only one application and only h.264 and vc-1 are supported. Not much.
                Open source driver uses shaders for decoding which increases heat and power consumption. UVD is left unused. So uvd/xvba are dead parts of silicon on Linux only wasting power.

                ATI always had bad drivers. Now situation improves on Windows but Linux support is only slight better than before. AMD gained better drivers by publishing docs. When Nvidia presented vdpau first time gave to community open source vdpau library, docs and patches to ffmpeg and mplayer for instant use. AMD made from XvBA secret by silently introducing additional xvba files which discovered and described Michael from Phoronix. Then AMD said that hackers will hack this api easily and provide support for players. This was crazy. This way AMD lost battle for being dominant video api on Linux. Nvidia won and Intel took second place.

                Direct2d is another AMD attempt to accelerate Linux but this M$ api does not fit to Linux. Nvidia wins again by taking different approach: they have universal core, with acceleration of everything and thin layers between core and os no matter if it is solaris/linux/bsd or windows. Nvidia knows that no matter what os is used all users want the same:OpenGL/accelerated video and 2D/power management. AMD again goes silly way: make driver for Windows and try to port it to Linux in spare time.

                Comment


                • #18
                  Originally posted by zbiggy View Post
                  Direct2d is another AMD attempt to accelerate Linux but this M$ api does not fit to Linux. Nvidia wins again by taking different approach: they have universal core, with acceleration of everything and thin layers between core and os no matter if it is solaris/linux/bsd or windows. Nvidia knows that no matter what os is used all users want the same:OpenGL/accelerated video and 2D/power management. AMD again goes silly way: make driver for Windows and try to port it to Linux in spare time.
                  We re-used the Direct2D switch variable (controlled by a registry key in Windows and an amdpcsdb key in Linux), not the actual acceleration code. The APIs are really different.

                  After people started getting excited that we were supporting Direct2D (which we weren't) we changed to a different switch name to avoid confusion.

                  This has been explained a few times already.
                  Test signature

                  Comment


                  • #19
                    Originally posted by devius View Post
                    I'd still like to add that the quality of the desktop experience is much worse with Radeons than it is either with Intel or nVidia gpus. In fact, the composited desktop experience (smoothness, responsiveness, number of rendering bugs) with Radeons is similar or worse to what you get on a measly 1st gen Atom netbook with it's crappy GMA950 gpu. This is when using either open source drivers or fglrx.
                    This might have been true at some point. But now, I compared same instance of Archlinux + KDE 4.7 with full compositing on a radeon HD5770 and an NVidia 240. Both with blobs. The NV sucks! You can't resize a window. It's slow as hell. Radeon flies through tho. I also tested with Nvidia 440, Ati 4650, HD3000. ATIs were superior with both, the blob and the open source drivers.

                    Don't think that the NVidia blob is perfect. I sold my NVidia and got me an ATI. I had issues with switching VTs, dual screen etc. At least I know, if the blob sucks, I can use the open source drivers, and they will preform great.

                    Comment


                    • #20
                      Originally posted by zbiggy View Post
                      @DanL We talk here about Catalyst for Linux. Not open source driver. With Catalyst OpenGL2 is not available when compositing is on according to KDE developer's blog who is responsible for graphics..
                      It's possible to force it if you want the kind of glitches that GNOME Shell users are experiencing. Plus the driver crashes if you try to run two apps that want direct rendering at once.

                      Comment

                      Working...
                      X