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 jrch2k8 View Post
    so the only way i see amd competing here is through opencl in the OSS driver when the tracker get functional enough, and based in the current state of the oss driver code quality i think opencl video accel is gonna be awesome too
    I don't believe OpenCL video acceleration can compete with dedicated HW like the UVD. You would need a high-end card and this won't be as power efficient as the UVD. I don't have figures for UVD, but a dedicated ASIC for video decoding is generally under 1W of power, and this is still being capable to cope with high bitrate H.264 encoded videos. From my point of view, OpenCL video acceleration is a myth and out of practical reality wrt. the above-mentioned constraints: power and performance.

    Comment


    • New updates avaible:

      libva 0.31.0-1+sds9
      xvba-video 0.5.2
      mplayer-vaapi 20091127

      splitted-desktop.com is your first and best source for all of the information you’re looking for. From general topics to more of what you would expect to find here, splitted-desktop.com has it all. We hope you find what you are searching for!

      Comment


      • Updated the script to use 0.5.2 as there are no latest links for the debs (download the script again). The "svn up" variant "-1" works again too. For nvidia the updates are really nice - now it is basically on par with vdpau mode - you can deinterlace with D. Maybe even DIVX works with new nvidia cards, could not test this. Best check vainfo with such a card.

        Comment


        • Originally posted by Qaridarium
          believe it or not you are wrong!

          wrong because the UVD2 unit itself use the GPU-shader
          There is no reason to believe you. If the UVD were using shading units, then AMD would have been able to implement MPEG-2 VLD, which is not possible because UVD functions set are fixed.

          Dirac!,Theora,OGG,FLAC and more future codexs
          I don't think you know what you are talking about. OGG is not a codec. You are probably living in an alternate reality. Care to show me the code that would make dual stream decoding of high birate H.264 videos possible on a poor RS780?

          Comment


          • Originally posted by Qaridarium
            "There is no reason to believe you. "

            longer time ago there was the same Tropic in this forum!..

            you can ask Bridgman about the UVD unit!

            Bridgman will say something like that: "yes the UVD unit use the shader for some functions. "
            You are interpreting facts and drawing wrong conclusions from those. The UVD does H.264 and VC-1 at VLD level. MPEG-2 MC/IDCT is done with shaders and that's inefficient because quite a bit of work still needs to be done on CPU. Video decode acceleration for H.264 partially worked with shaders in previous GPUs because they started at the MC entry-point, not VLD. And this was terribly limited.

            Nowadays, the shaders are only used for colorspace conversion and some other *post* processing. The core video decoding is done by the specific ASIC (UVD). Again, show me code proving what you say (or what you are dreaming of).

            Comment


            • OK, here's my understanding :

              - UVD handles the top half of the playback stack (decoding), when present. This includes bitstream / IQ / IDCT / deblocking / MC for H.264/VC-1 and IDCT / MC for MPEG2.

              - The bottom half of the playback stack (scaling, color space conversion, post-filtering, not sure about adaptive deinterlacing) is done on shaders.

              - UVD's HW programming interface is tied pretty closely to the DRM blocks so I'm telling people to assume that we will *not* be able to provide programming docs for open source drivers. Once we get through the current work and have a chance to spend some quality time with UVD we should be able to give a definitive answer.

              For decode acceleration without UVD, I expect that MC, deblocking etc will be a good fit for shaders, while bitstream decode, IQ and IT will probably stay on CPU. That partitioning should work pretty well -- not too hard on the GPU, but offloading enough CPU that a single core should be able to keep up. There were some efforts to move IT onto shaders but with the simplified IDCT algorithm in H.264 (and VC-1 ?) the CPU load is lower than before so it seems best to leave on the CPU.
              Last edited by bridgman; 28 November 2009, 03:06 PM.
              Test signature

              Comment


              • All my mplayer-vaapi scripts are updated and use 0.5.3 xvba-video. I would prefer that the debs would be also available as "latest" instead of the version then i don't have to update it everytime. But it is really nice update for xvba users:

                Version 0.5.3 - 28.Nov.2009
                * Handle up to 16 subpictures in OpenGL rendering mode too

                That means OSD finally works with opengl output! It does not fix color rendering problems or stability issues but at least you can use OSD/subtitles. Now i want m2ts subtitles for mplayer and xvba support for mpeg1/2 too - then you don't need to switch from vaapi to gl everytime. A fallback for other codecs should be possible too just like using a clever vdpau config. Btw. as mplayer (or better ffmpeg) has broken mpc support there is currently a -2 script with a hotfix too.

                Comment


                • Does it still need the ATI 9.10 driver or does it work with 9.11 too?

                  Comment


                  • I only tested 9-10.

                    Comment


                    • Having a great mixture of information and entertainment, this thread seriously wins. Anyone wants some popcorn?

                      Comment

                      Working...
                      X