Announcement

Collapse
No announcement yet.

AMD's UVD2-based XvBA Finally Does Something On Linux

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

  • Originally posted by mugginz View Post
    Even if it is initially non-trivial, most technically proficient users will be able to deal with just about anything really. But there's two problems I see straight away. Firstly, and most importantly, it's not usually something you can require of non-technically minded users, so when things like this are required for reasonable performance, it rules out garden variety users. Secondly, while there are no-fuss alternatives (say like nVidia) it diminishes the desire to fiddle in this area somewhat.
    AFAIK AMD/ATI will soon release a new 2d stack for fglrx. This will solve this issue and make the current 2d acceleration (with the above patch) even faster. I think the new 2d acceleration is called direct2d and is included in the fglrx drivers > 10.2?

    Originally posted by mugginz View Post
    With respect to GPU video decode, if you have a reasonably modern machine then most video will decode on the CPU without much issue if that's all that's happening. When you're loading your machine with a larger background load, this can present problems when also having to do CPU decode as well. Thankfully I've not bought an Evergreen card yet so am not in as much of a hurry for this support as others with cards already.
    I have to ask you this. What do you possible want to use your cpu for, while watching a movie?

    Comment


    • Originally posted by Hans View Post
      AFAIK AMD/ATI will soon release a new 2d stack for fglrx. This will solve this issue and make the current 2d acceleration (with the above patch) even faster. I think the new 2d acceleration is called direct2d and is included in the fglrx drivers > 10.2?
      I'm not sure if it's fully exposed in the current drivers but solid 2D is getting closer and closer.


      Originally posted by Hans View Post
      I have to ask you this. What do you possible want to use your cpu for, while watching a movie?
      Well, currently just running torrents (legitimate ones), email, twitter, skype, sometimes 3D rendering, various odds and sods, and I have a bad habit of surfing the web on one screen while watching something else on the other. GPU decode vastly diminishes the other stuff from impacting the smooth playback on the other screen.

      Comment


      • Originally posted by Hans View Post
        Look at my answers to Panix.

        Oh and btw. Again I want to emphasize, that I am not telling you to bye fglrx over nvidia. I am just telling you that fglrx isn't that bad really.
        I have had fglrx in over two years now, and the improvements done within these two years with fglrx is enormous.
        I do want to buy ATI over nVidia, and likely will soon be able to. As you and others have noted the drivers are improving at a decent rate. I guess I'm just being clear that while solid support is on its way, it's not quite here yet. Some seem to be taking the various posts stating fglrx et al. aren't really that bad and mostly work for a lot of things as verification that it's all go for a mainly painless experience with ATI cards.

        Comment


        • Originally posted by mugginz View Post
          Well, currently just running torrents (legitimate ones), email, twitter, skype, sometimes 3D rendering, various odds and sods, and I have a bad habit of surfing the web on one screen while watching something else on the other. GPU decode vastly diminishes the other stuff from impacting the smooth playback on the other screen.
          I have just testet my cpu usage while playing two movies on my computer.
          Using top as benchmark tools I got these numbers of cpu usage on 1 core.

          Code:
          Movie resolution:  fps:      cpu usage (peak when there were a lot of movement in the scene):
          1280x528 (720p)    24        ~65%
          624x336            25        ~20%
          As you can see. I don't have any problems decoding these movies. But ofcourse I might have problems with 1080p.

          My cpu:
          Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz

          I think the problem is outdated, as Q stated earlier in this thread.

          Comment


          • Originally posted by mugginz View Post
            I do want to buy ATI over nVidia, and likely will soon be able to. As you and others have noted the drivers are improving at a decent rate. I guess I'm just being clear that while solid support is on its way, it's not quite here yet. Some seem to be taking the various posts stating fglrx et al. aren't really that bad and mostly work for a lot of things as verification that it's all go for a mainly painless experience with ATI cards.
            Good idea. It is always better to be safe than sorry.

            Comment


            • Originally posted by Hans View Post
              As you can see. I don't have any problems decoding these movies. But ofcourse I might have problems with 1080p.

              My cpu:
              Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz

              I think the problem is outdated, as Q stated earlier in this thread.
              1080p can introduce a fair bit of a hit and is much more susceptible to latency issues introduced by busy background stuff. Not a major deal killer for me personally, but more so for someone with a more modest system who's more easily annoyed by frame stutter.

              Comment


              • @gebauche

                I know decoding a movie in opencl is not as good as dedicated hardware. But how hard do you think it would be to write a h.264 opencl implementation, which uses the vaapi api?

                I think it could be a funny summer vacation project.

                Comment


                • Originally posted by Qaridarium
                  you can not believe that wine will NOT work? thats really funny! because winehq write this in the chancelog!
                  wine 1.1.43: "wined3d: Don't use GLSL if the supported version isn't at least 1.20. "
                  mesa7.8 only have ogl2.0 for the hd4xxx cards

                  ok some infos for you if you wana be sure thats all fine if you buy a amd card!

                  wait for the linux kernel 2.6.34! because this is the first kernel with full energysave support for the amd cards.

                  wait for the mesa 7.9! because this version will have OGL2.1! thats because games like HON need OGL2.1! and wine need OGL2.1!

                  if you wana more opensource features you need to wait longer if you wana buy a hd5xxx i think you need wait a bit

                  galium brings nice features in the opensource world to the hd5xxx faster cpu raseriser for non supportet extansions and also much more 'speed' and i think in generall OGL3+
                  So, in a nutshell, the HD 4xxx series of cards allows all features and no issues or is there issues? I would like an objective opinion here if there is ANYTHING to speak of regarding issues. It sounds like even Wine works?

                  If I go with a HD 5000 series card, the fglrx driver works but I would like to know if there is issues with that. 2D has been reported in the past to have some issues like tearing. I am wondering how prominent this is and what is the specific update on this.

                  I understand FOSS drivers are not available for the HD 5000 cards but this is a WIP type deal. Since I watch movies and streaming video (on occasion, such as YouTube) on my computer, I need a quality picture and related features. I wish the support updates and 'fixes' were quicker but if video quality is there, I could wait if there are no 'dealbreaker' issues with whatever driver is available. I couldn't excuse major issues like tearing or ones that prevent full use of the card. The problem is I wouldn't know how long I'd have to wait.

                  It seems like lack of XV/XvMA support has been going on forever so these long-waited features and functions of the card which should be available if AMD/ATI really support Linux is worrisome to me, at least. I think the excuse that the overall support was started late can't be used infinitely. At some point, there has to be a major investment to get this support progressions out more quickly. Find a way or something?!? *BOTH* Linux and Windows users want or would prefer to use ATI cards right now because of hardware. Few people switch because of the drivers unless you're a die-hard FOSS driver fanatic who doesn't care about how long the support fixes happen. I don't want to be a 2nd choice, down in the hierarchy of priorities or play 2nd or 3rd fiddle to Workstation ppl. If both can't be accommodated, then I can't justify an ATI purchase unless I'm going to use Windows anyway. You would just have constant driver problems which would hamper your use of the card. I'd have no choice but to get a Nvidia card.

                  Comment


                  • Originally posted by bridgman View Post
                    Once the Gallium3D driver and LLVM-compiled SW TCL starts working on your hardware you might be pleasantly surprised.

                    One of the biggest differences between the Catalyst driver and open source drivers on your chip was the software TCL code (aka running vertex shaders on the CPU). That code was pretty slow on classic mesa but apparently the LLVM compiler generates very efficient code, so hopefully you should see open source performance that is closer to Catalyst than what you have seen previously.

                    Don't think SW TCL is working yet on the Gallium3D driver but keep your eyes open for it.
                    wow, bridgeman, your saying your replying on generic LLVM to generate sane L0/L1 etc code when its well know it uses much off GGC and that has serious problems producing efficiant code as can be witnessed if you just go ask the assembly code devs on #x264 and #x264dev IRC channels.

                    are you as inthe AMD/ATI devs etc trully not helping fix these many GGC/LLVM problems with patches to at least help produce far better cache assembly code so helping G3 and other video related apps ?

                    Comment


                    • Originally posted by bridgman View Post
                      Once the Gallium3D driver and LLVM-compiled SW TCL starts working on your hardware you might be pleasantly surprised.

                      One of the biggest differences between the Catalyst driver and open source drivers on your chip was the software TCL code (aka running vertex shaders on the CPU). That code was pretty slow on classic mesa but apparently the LLVM compiler generates very efficient code, so hopefully you should see open source performance that is closer to Catalyst than what you have seen previously.

                      Don't think SW TCL is working yet on the Gallium3D driver but keep your eyes open for it.
                      wow, bridgeman, your saying your replying on generic LLVM to generate sane L0/L1 etc code when its well know it uses much off GGC and that has serious problems producing efficiant code as can be witnessed if you just go ask the assembly code devs on #x264 and #x264dev IRC channels.

                      are you as in the AMD/ATI devs etc trully not helping fix these many GCC/LLVM problems in a timely mannor with patches to at least help produce far better cache assembly code so helping G3D and other video related apps as they become known and tested against highly optimised apps such as x264cli etc ?

                      Comment

                      Working...
                      X