Announcement

Collapse
No announcement yet.

AMD Releases Open-Source UVD Video Support

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

  • deathsimple many thanks for UVD support

    1.) the kernel patch fails to compile in vanilla 3.8.4 since your are using a couple of patches that are not present in 3.8 drm series like the cs_parser and couple other symbols, luckily seems can be easily backported from 3.9 drm code and i got it to build[not sure if will work tho]

    2.) mesa patch don't apply cleanly nor build with mesa master the makefile.AM patches make the whole set gallium drivers not build or/and generate a bazillion of missing symbols in r600g, radeon, radeonsi drivers

    not bitching just saying since i have an 7770 and 9.1.1 series mesa make my desktop unusable while master is peachy beyond some stupid render glitches is perfectly fine, so i really wanna try those patches on CAPE VERDE but i can find a way to apply the patch to master, could you check it out and post a more recent one or you have any idea when will your patch will reach master? ofc im trying to fixing it too but you since you know the code better maybe you have working already

    Comment


    • Hi,

      A Gentoo dev has been so kind and packaged it up. If you want to experiment, here are the links :
      1) Kernel 3.8 : http://dev.gentoo.org/~chithanh/radeon-uvd/ (take version 2)
      2) Mesa master http://distfiles.gentoo.org/distfile...hes-01.tar.bz2

      Serafean

      Nice gentoo dev : http://chithanh.blogspot.com/2013/04...venturous.html

      Comment


      • Originally posted by bridgman View Post
        Re: patents, the concern there is IP which is currently protected by trade secret but where we have patent applications in flight internally.
        This might sound stupid since I don't quite understand all this, but

        Couldn't you just put all the secret stuff into microcode (the "How to manage power" part) and just call it later with "I need this to spin down, reclock, etc" by calling the thing from microcode?

        Comment


        • Perfectly reasonable question. The downside with that approach is that we would need to write and validate a completely different set of microcode for the open source drivers, and that's a big honkin' pile of work. There are also limits to the size of the microcode - basically limited to the size of the on-chip microcode store for that block.

          Comment


          • Originally posted by Serafean View Post
            Hi,

            A Gentoo dev has been so kind and packaged it up. If you want to experiment, here are the links :
            1) Kernel 3.8 : http://dev.gentoo.org/~chithanh/radeon-uvd/ (take version 2)
            2) Mesa master http://distfiles.gentoo.org/distfile...hes-01.tar.bz2

            Serafean

            Nice gentoo dev : http://chithanh.blogspot.com/2013/04...venturous.html
            ah sorry to be ranting, but I saw UVD 3.9 already :O . Anyway neat for gentoo users, too bad I am still on arch

            Comment


            • Originally posted by Serafean View Post
              Hi,

              A Gentoo dev has been so kind and packaged it up. If you want to experiment, here are the links :
              1) Kernel 3.8 : http://dev.gentoo.org/~chithanh/radeon-uvd/ (take version 2)
              2) Mesa master http://distfiles.gentoo.org/distfile...hes-01.tar.bz2

              Serafean

              Nice gentoo dev : http://chithanh.blogspot.com/2013/04...venturous.html
              thx very much for the info

              going to emerge now XD

              Comment


              • Originally posted by jrch2k8 View Post
                thx very much for the info

                going to emerge now XD
                Please tell me if you got it working. I got something when I enabled the vdpau mesa useflag, but I suspect that only enabled the gallium VDPAU tracker... Anyway
                Code:
                 [drm] UVD initialized successfully.
                is good!

                Comment


                • Originally posted by Serafean View Post
                  Please tell me if you got it working. I got something when I enabled the vdpau mesa useflag, but I suspect that only enabled the gallium VDPAU tracker... Anyway
                  Code:
                   [drm] UVD initialized successfully.
                  is good!
                  yes is working fine for H.264 and Divx/Xvid in Cape Verde

                  mpeg1/2 green screen -> artifacts gpu goes crazy
                  WMV3 goes all black screen

                  Comment


                  • If VDPAU acceleration is in use, mplayer will show something like this:
                    Code:
                    VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration
                    By specifying or omitting "-vc ffh264vdpau,ffwmv3vdpau," etc. parameter you can enable/disable acceleration for individual codecs. The comma at the end of the list is important. To my knowledge, ffwmv3vdpau and ffvc1vdpau are still experimental and not expected to work well.
                    Last edited by chithanh; 04-08-2013, 09:02 AM. Reason: clarify more what does not work

                    Comment


                    • Originally posted by chithanh View Post
                      If VDPAU acceleration is in use, mplayer will show something like this:
                      Code:
                      VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration
                      By specifying or omitting "-vc ffh264vdpau,ffwmv3vdpau," etc. parameter you can enable/disable acceleration for individual codecs. The comma at the end of the list is important. To my knowledge, ffwmv3vdpau and ffvc1vdpau are still experimental and not expected to work well.
                      yes i did so, ill try to figure out later how to debug it. especially why mpeg1/2 corrupt the gpu framebuffer and have to restart to restore

                      Comment


                      • Finally did some testing on my card. It's CAYMAN series ( HD6950 )
                        Code:
                        01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cayman PRO [Radeon HD 6950]
                        so it should be the same as found in APUs of the HD7XXX series, if my memory serves right. firmware needed : SUMO_rlc.
                        • MPEG1/2, tested with http://inventaaustralia.zftp.com.nyu...3MBPS30sec.mpg : WORKS; mplayer : [ffmpeg12vdpau] vfm : ffmpeg (FFmpeg MPEG-1/2 (VDPAU))
                        • H264, tested with Sintel & Tears of Steel : WORKS ;mplayer output : [ffh264vdpau] vfm : ffmpeg (FFmpeg H.264 (VDPAU))
                        • MPEG4 (assumed, decoded with ffodivxvdpau), tested with personnal video (from camera & transcoded) : WORKS ; mplayer : [ffodivxvdpau] vfm : ffmpeg (FFmpeg MPEG-4,DIVX-4/5 (VDPAU))
                        • VC1, tested with http://samples.mplayerhq.hu.nyud.net..._51_15Mbps.wmv : FAILS with artefacts and green window, enabling -vc ffwmv3vdpau completely hangs the card.

                        This was tested with mplayer -vo vdpau -vc ffmpeg12vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau,

                        xbmc hangs when vdpau is enabled.

                        Serafean

                        Comment


                        • I simply wouldn't have believed it.

                          Comment


                          • Originally posted by Serafean View Post
                            Finally did some testing on my card. It's CAYMAN series ( HD6950 )
                            Code:
                            01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cayman PRO [Radeon HD 6950]
                            so it should be the same as found in APUs of the HD7XXX series, if my memory serves right. firmware needed : SUMO_rlc.
                            • MPEG1/2, tested with http://inventaaustralia.zftp.com.nyu...3MBPS30sec.mpg : WORKS; mplayer : [ffmpeg12vdpau] vfm : ffmpeg (FFmpeg MPEG-1/2 (VDPAU))
                            • H264, tested with Sintel & Tears of Steel : WORKS ;mplayer output : [ffh264vdpau] vfm : ffmpeg (FFmpeg H.264 (VDPAU))
                            • MPEG4 (assumed, decoded with ffodivxvdpau), tested with personnal video (from camera & transcoded) : WORKS ; mplayer : [ffodivxvdpau] vfm : ffmpeg (FFmpeg MPEG-4,DIVX-4/5 (VDPAU))
                            • VC1, tested with http://samples.mplayerhq.hu.nyud.net..._51_15Mbps.wmv : FAILS with artefacts and green window, enabling -vc ffwmv3vdpau completely hangs the card.

                            This was tested with mplayer -vo vdpau -vc ffmpeg12vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau,

                            xbmc hangs when vdpau is enabled.

                            Serafean
                            I have made it work for E-350 with
                            Kernel 3.9-rc6 + drm uvd patches (3.8 + patches didn't work for me)
                            libdrm Git 08.04.2013
                            xorg-server 1.13.3
                            Mesa Git 08.04.2013 + uvd patch

                            Overall I am very please with results as there is a way for open source driver to finally playback 1080p H264 content with just very limited CPU use It is not without rough edges on one can see on the bug 63090.

                            For XBMC & Vdapu https://github.com/FernetMenta/xbmc has to be used. It works, but not all that smooth. Probably some more fixes are needed to their vdpau implementation

                            PS vdpauinfo reveled for me as there is no deinterlancing capabilities in the driver I hope that will change in the future as well

                            Comment


                            • Originally posted by bridgman View Post
                              Perfectly reasonable question. The downside with that approach is that we would need to write and validate a completely different set of microcode for the open source drivers, and that's a big honkin' pile of work. There are also limits to the size of the microcode - basically limited to the size of the on-chip microcode store for that block.
                              I saw someone saying that part of UVD is implemented in microcode so I thought maybe secret pm bits could be implemented too. I wasn't aware of any limitations though. Too bad.

                              Oh and by the way, do you know (or are you allowed to tell us) if there are any plans for EGL in the proprietary driver?

                              Comment


                              • And does anyone happen to know if UVD will work with hybrid graphics? airlied said it might in theory work with DRI_PRIME. Can anyone confirm this who/if someone got it set up?

                                Comment

                                Working...
                                X