Announcement

Collapse
No announcement yet.

Where An Open ATI Driver Beats The Catalyst Driver

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

  • #21
    Originally posted by 0e8h View Post
    I also like how the open source Radeon driver also has a higher resolution for the text modes. FGLRX looks like it uses 40x40 text cols. I feel like I'm starting a BBC Acorn Computer, not a modern linux system.
    Acorn. You mean the early model of the arm processor.

    Comment


    • #22
      Originally posted by V!NCENT View Post
      So the CPU spike while the GPU is busy too? My CPU usage gets no worse than 40% with a HD5770 framebuffer (no vid decode) with a downloaded matroska 720p vid on KDE4. It is a two year old AMD Phenom 9950 x4 non-OC.

      What the fsck... so how is GPU playback drawing less power?

      However someday I think the FLOSS ATI drivers will beat fglrx at anything except top speed.
      The problems is, I think!, that when the video card does it's bus mastering to get the data it needs. The CPU is idle but locked up by the equivalent of a hardware semaphore for non use. So it' reads as usage spike on cpu.

      Comment


      • #23
        Does anyone know what is the state of gl video support in the open driver? It is worked on? Right now it is a nightmare with softwares that don't use xv (XBMC, for example): anything below 720p is totally unwatchable with an Athlon II X2 235e (2.7 Ghz).

        Comment


        • #24
          Originally posted by 0e8h View Post
          I also like how the open source Radeon driver also has a higher resolution for the text modes. FGLRX looks like it uses 40x40 text cols. I feel like I'm starting a BBC Acorn Computer, not a modern linux system.
          That's a direct result of KMS (only found in open-source drivers, not fglrx or nvidia). You can increase the text-mode resolution on closed-source drivers but they tend to be too slow for that (especially on nvidia cards).

          Comment


          • #25
            The article didn't mention that Xv on Catalyst is supposed to be useless? Wrong colors, no vsync...

            Why?

            Comment


            • #26
              Originally posted by BlackStar View Post
              That's a direct result of KMS (only found in open-source drivers, not fglrx or nvidia). You can increase the text-mode resolution on closed-source drivers but they tend to be too slow for that (especially on nvidia cards).
              Looks real professional having the higher text resolution.

              It makes the start up mode also high res. Not sure if this is VESA emulation on the Radeon card or some other video mode.

              I noticed when you build a kernel you can set the resolution. Is that what you mean by KMS? Is the module setting these values as it docks into the kernel?

              Comment


              • #27
                Originally posted by 0e8h View Post
                Looks real professional having the higher text resolution.

                It makes the start up mode also high res. Not sure if this is VESA emulation on the Radeon card or some other video mode.

                I noticed when you build a kernel you can set the resolution. Is that what you mean by KMS? Is the module setting these values as it docks into the kernel?
                No, that's for a framebuffer. If you want KMS, go to Device Drivers -> Graphics Support -> Direct Rendering Manager Support -> ATI Radeon ->[*] Enable modesetting in radeon by default - NEW DRIVER

                in your kernel config on a recent kernel.

                Comment


                • #28
                  Originally posted by kbios View Post
                  Does anyone know what is the state of gl video support in the open driver? It is worked on? Right now it is a nightmare with softwares that don't use xv (XBMC, for example): anything below 720p is totally unwatchable with an Athlon II X2 235e (2.7 Ghz).
                  I tested a 720p video with my old laptop (Intel(R) Pentium(R) M processor 1.60GHz) and the latest git drivers (kernel from drm-radeon-testing branch). Compiz was enabled.
                  With mplayer -vo xv: 50% load
                  With mplayer -vo gl: 65% load

                  Good quality with both output methods: no tearing, right colors.
                  I use Xbmc on my desktop pc (HD4850) and everything is fine.

                  Comment


                  • #29
                    Originally posted by Perry3D View Post
                    I tested a 720p video with my old laptop (Intel(R) Pentium(R) M processor 1.60GHz) and the latest git drivers (kernel from drm-radeon-testing branch). Compiz was enabled.
                    With mplayer -vo xv: 50% load
                    With mplayer -vo gl: 65% load

                    Good quality with both output methods: no tearing, right colors.
                    I use Xbmc on my desktop pc (HD4850) and everything is fine.
                    Thanks, 720p works good here also. 1080p works with mplayer and xv/x11/sdl outputs, but it is slow with gl/gl2 ones (framedrops, audio out of sync). The problem is that XBMC only supports those outputs (it calls them "basic shaders" and "advanced shaders"), so I am forced right now to use an external player. By the way, my video card is an HD4200.

                    Comment


                    • #30
                      Originally posted by Michael View Post
                      It shouldn't be a compilation problem, but the main point of this article anyways as expressed is about the X-Video performance, which is clear.
                      Michael, please remove the XvBA results from the figure. They are obviously wrong. You can say XvBA visually mis-decodes some clips, crashes, memory leaks and whatever obscure problem, but you cannot say the CPU remains at 95% when it is, supposedly, enabled. The point is some people (e.g. the famous Q) would say: hey, look, VPU decoding is not competitive vs. CPU decoding.

                      In summary, you most likely forgot the extra -va vaapi option. This means VA-API VO was used but decoding was done on CPU. i.e. CPU decoded frames are uploaded to VA surfaces. Doing so, the performance is similar to Xv.

                      Comment

                      Working...
                      X