Announcement

Collapse
No announcement yet.

AMD Releases Open-Source UVD Video Support

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

  • phoronix
    started a topic AMD Releases Open-Source UVD Video Support

    AMD Releases Open-Source UVD Video Support

    Phoronix: AMD Releases Open-Source UVD Video Support

    Within the next few hours AMD will be publishing open-source driver code that exposes their Unified Video Decoder (UVD) engine on modern Radeon HD graphics cards. This will finally allow open-source graphics drivers to take advantage of hardware-accelerated video decoding. Read more details in this Phoronix exclusive.

    http://www.phoronix.com/vr.php?view=18602

  • smitty3268
    replied
    Originally posted by droidhacker View Post
    I already pointed out that it indicates that it is only capable of mpeg2 decoding, which means its definitely NOT UVD. Mpeg2 really shouldn't take up 30% CPU, even 1080p, except maybe on a crap CPU like an atom.

    Which suggests, of course, that even if he has some shader based decoder available, he's still most likely using straight software decoding, and probably decoding some variation of mpeg4. After all... there aren't very many sources of HD mpeg2.
    Well, i guess i was assuming that he had tried out playing videos before and after he tried installing the vdpau support, and saw a big difference. Which suggested that he was getting the shader based decoder, rather than nothing, because in that case he wouldn't have seen any difference. But i guess it's possible he didn't even try out the software decoding to compare it.

    Leave a comment:


  • droste
    replied
    Originally posted by smitty3268 View Post
    He's probably running mpeg2. I think that indicates the shader based decoder.
    The information string is the same with UVD, but "Decoder capabilities" lists for example mpeg4:

    Code:
    Decoder capabilities:
    
    name               level macbs width height
    -------------------------------------------
    MPEG1                16  9216  2048  1152
    MPEG2_SIMPLE         16  9216  2048  1152
    MPEG2_MAIN           16  9216  2048  1152
    H264_BASELINE        16  9216  2048  1152
    H264_MAIN            16  9216  2048  1152
    H264_HIGH            16  9216  2048  1152
    VC1_SIMPLE           16  9216  2048  1152
    VC1_MAIN             16  9216  2048  1152
    VC1_ADVANCED         16  9216  2048  1152
    MPEG4_PART2_SP       16  9216  2048  1152
    MPEG4_PART2_ASP      16  9216  2048  1152

    Leave a comment:


  • droidhacker
    replied
    Originally posted by smitty3268 View Post
    He's probably running mpeg2. I think that indicates the shader based decoder.
    I already pointed out that it indicates that it is only capable of mpeg2 decoding, which means its definitely NOT UVD. Mpeg2 really shouldn't take up 30% CPU, even 1080p, except maybe on a crap CPU like an atom.

    Which suggests, of course, that even if he has some shader based decoder available, he's still most likely using straight software decoding, and probably decoding some variation of mpeg4. After all... there aren't very many sources of HD mpeg2.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by droidhacker View Post
    ... what kind of file are you decoding? Is it mpeg1/2 or mpeg4/h263/h264? If any of the latter, you're definitely software decoding. Notice what it says under "decoder capabilities". Depending on your CPU, 30% may make perfect sense. A Sempron 140 can *almost* handle a 1080p h264 in software, so any middle-of-the-road quad-core would probably take about 30%-ish.

    Note that UVD should take about 0%.
    He's probably running mpeg2. I think that
    Information string: G3DVL
    indicates the shader based decoder.

    Leave a comment:


  • droidhacker
    replied
    Originally posted by ptarcher View Post
    My vdpauinfo outputs the following

    Code:
    $ vdpauinfo
    display: :0   screen: 0
    API version: 1
    Information string: G3DVL VDPAU Driver Shared Library version 1.0
    
    Video surface:
    
    name   width height types
    -------------------------------------------
    420     8192  8192  NV12 YV12 
    422     8192  8192  NV12 YV12 UYVY YUYV 
    444     8192  8192  NV12 YV12 Y8U8V8A8 V8U8Y8A8 
    
    Decoder capabilities:
    
    name               level macbs width height
    -------------------------------------------
    MPEG1                16 262144  8192  8192
    MPEG2_SIMPLE         16 262144  8192  8192
    MPEG2_MAIN           16 262144  8192  8192
    
    Output surface:
    
    name              width height nat types
    ----------------------------------------------------
    B8G8R8A8          8192  8192    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
    R8G8B8A8          8192  8192    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
    R10G10B10A2       8192  8192    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
    B10G10R10A2       8192  8192    y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 
    
    Bitmap surface:
    
    name              width height
    ------------------------------
    B8G8R8A8          8192  8192
    R8G8B8A8          8192  8192
    R10G10B10A2       8192  8192
    B10G10R10A2       8192  8192
    A8                8192  8192
    
    Video mixer:
    
    feature name                    sup
    ------------------------------------
    DEINTERLACE_TEMPORAL             -
    DEINTERLACE_TEMPORAL_SPATIAL     -
    INVERSE_TELECINE                 -
    NOISE_REDUCTION                  y
    SHARPNESS                        y
    LUMA_KEY                         -
    HIGH QUALITY SCALING - L1        -
    HIGH QUALITY SCALING - L2        -
    HIGH QUALITY SCALING - L3        -
    HIGH QUALITY SCALING - L4        -
    HIGH QUALITY SCALING - L5        -
    HIGH QUALITY SCALING - L6        -
    HIGH QUALITY SCALING - L7        -
    HIGH QUALITY SCALING - L8        -
    HIGH QUALITY SCALING - L9        -
    
    parameter name                  sup      min      max
    -----------------------------------------------------
    VIDEO_SURFACE_WIDTH              y        48     8192
    VIDEO_SURFACE_HEIGHT             y        48     8192
    CHROMA_TYPE                      y  
    LAYERS                           y         0        4
    
    attribute name                  sup      min      max
    -----------------------------------------------------
    BACKGROUND_COLOR                 y  
    CSC_MATRIX                       y  
    NOISE_REDUCTION_LEVEL            y      0.00     1.00
    SHARPNESS_LEVEL                  y     -1.00     1.00
    LUMA_KEY_MIN_LUMA                y  
    LUMA_KEY_MAX_LUMA                y
    And when playing with mplayer it only uses 30% CPU with perfectly smooth playback. I can actually play at least 2 HD video's at the same time with dynamic resize. Where should I be looking furthur to find if I am using shader based vdpau implementation in mesa or software rendering?
    ... what kind of file are you decoding? Is it mpeg1/2 or mpeg4/h263/h264? If any of the latter, you're definitely software decoding. Notice what it says under "decoder capabilities". Depending on your CPU, 30% may make perfect sense. A Sempron 140 can *almost* handle a 1080p h264 in software, so any middle-of-the-road quad-core would probably take about 30%-ish.

    Note that UVD should take about 0%.

    Leave a comment:


  • droidhacker
    replied
    Originally posted by agd5f View Post
    It looks like you are using the shader-based implementation.
    Originally posted by Deathsimple View Post
    Yep definitively shader based decoding.
    I'm anxious on the RS780/880 support... any news?

    Leave a comment:


  • Hugh
    replied
    (I'm sorry for my slow response. I didn't get notification of your posting (surely my fault) and I almost never on this forum. This topic is particularly important to me.)

    Originally posted by bridgman View Post
    Hal2k1 was mentioning copyright. I included it in the larger list for completeness. Re: patents, the concern there is IP which is currently protected by trade secret but where we have patent applications in flight internally.
    OK. That explanation makes more sense.

    I don't see how it applies in all cases that we're talking about, but I guess that might be a consequence of it being a secret.


    Intel had been working on releasing materials to open source for years before we started. If you said "the sad thing is that in 10 years (or maybe 8, not sure) Intel has reached sufficient performance for video..." I would agree. I'm sure we will reach at least the same level in the same time.
    I guess that I wasn't clear. I was rooting for ATI/AMD. ATI/AMD had a significant (large) and consequential (qualitatively important to many Linux users) performance advantage over Intel video. For my purposes, Intel's HD 2000 and up performance is finally good enough: it can do the 3d acceleration (perhaps needlessly) required by modern Linux desktops, and it can reasonably do video decoding. A window has closed.

    It's amazing that nVidia, with its closed source drivers, has so much mindshare in the Linux world. It looks to me as if the reason is that they take great care of their Linux driver so that it is almost always up to date with the current production kernels, and it isn't too buggy. ATI/AMD's closed drivers haven't managed that.

    ATI/AMD could get a free-er ride with open source. But I admit that the vast majority of the work on the Intel open-source drivers is done by Intel staff.

    BTW, IMHO, Years ago, ATI should have harnessed Dave Arlie, not muzzled him.

    Leave a comment:


  • fritsch
    replied
    What about starting with a look at yadif: http://avisynth.org.ru/yadif/yadif.html?

    Leave a comment:


  • Deathsimple
    replied
    Originally posted by agd5f View Post
    It looks like you are using the shader-based implementation.
    Yep definitively shader based decoding.

    BTW: Does anybody volunteer to implement advanced deinterlacing? Or does anybody has a good & open source sample implementation?

    Christian.

    Leave a comment:

Working...
X