Announcement

Collapse
No announcement yet.

AMD Releases UVD Video Decode Support For R600 GPUs

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

  • #21
    The definition of "VDAPU/OpenGL interop" being...?

    Originally posted by brent View Post
    VDPAU-GL interop is required for some software that implements custom video postprocessing or scaling, like XBMC or mpv. The interop API is based on fields, even for progressive content.
    We are talking about an implementation of OpenGL extension GL_NV_vdpau_interop, correct?

    Because if so, then it would seem that Flash playback would be supported without this:

    $ strings libflashplayer.so | grep GL_
    on GL_NVI
    GL_ARB_multitexture
    GL_ARB_shader_objects
    GL_ARB_texture_rectangle
    GL_ARB_pixel_buffer_object
    GL_EXT_framebuffer_object
    GL_ARB_shading_language_100
    GL_ARB_fragment_shader
    GL_ARB_texture_non_power_of_two
    Last edited by chrisr; 08-24-2014, 02:06 PM.

    Comment


    • #22
      Originally posted by chrisr View Post
      We are talking about an implementation of OpenGL extension GL_NV_vdpau_interop, correct?
      Yes. Like I said, the API is field-based, and field output apparently isn't supported by those old R600 GPUs. I guess it should be possible to make this work with some additional overhead (buffer copies) though.

      Comment


      • #23
        Sure there are also non-mobile versions but for mobile users this is absolutely great!
        Right, but as I wrote, you can sell your old hardware, otherwise it would be of course be more expensive.

        Comment


        • #24
          I think it's pretty cool they did this. At this point most of this older hardware is only good for video decoding anyway so it can help breathe life into these old systems that many may have considered retiring. I think it's more important to get UVD and VDPAU completed before optimizing or adding anything else to these older cards; anything related to gaming I'd prefer be focused on newer cards. Now all they need to do is complete VDPAU.

          Comment


          • #25
            Originally posted by opensource View Post
            AMD and other devs, if developing for older hardware does not help support new hardware then please don't waste your time writing code for old hardware. New and newer hardware has more users and new hardware is also faster/better. Get over it and sell your old hardware and buy new hardware (200$ extra per 3years is nothing). Intel has great open source drivers BTW, they even have a team called The Intel Open Source Technology Center. Unfortunately they don't have AM/NV like graphics cards but regarding CPU I'd buy Intel.
            Find me an AMD GPU for $10 that's newer than a Radeon HD 2400 PRO, and I may be interested in your proposal to buy newer hardware.

            Also, who cares what CPU you'd buy? If I was going to buy some soft drink, I'd go for Pepsi

            Originally posted by schmidtbag View Post
            I think it's pretty cool they did this. At this point most of this older hardware is only good for video decoding anyway so it can help breathe life into these old systems that many may have considered retiring. I think it's more important to get UVD and VDPAU completed before optimizing or adding anything else to these older cards; anything related to gaming I'd prefer be focused on newer cards. Now all they need to do is complete VDPAU.
            I have an older desktop with a Radeon HD 2400 PRO that could use some VDPAU; I run Plex Home Theater on it. Although I'm interested in:

            Originally posted by libv View Post
            rv6xx is everything but the r600: the HD2900, which upon announcement supposedly had uvd, but two days later this was correct. Apparently that block was broken on r600. So you're talking hd2400, hd2600 (if synapses serve, as this 7y old info is purely off the top of my head) and such as well.
            So does that mean this news doesn't apply to a 2400? I assume the 2400 and 2400 PRO are the same?

            Comment


            • #26
              Originally posted by Espionage724 View Post
              I assume the 2400 and 2400 PRO are the same?
              On the desktop side, HD 2400 doesn't exists. There is only 2400 Pro and 2400 XT.
              And both are RV610.

              Originally posted by Espionage724 View Post
              So does that mean this news doesn't apply to a 2400?
              So HD 2400 is concerned by this news.
              Last edited by whitecat; 08-24-2014, 04:36 PM.

              Comment


              • #27
                I had some short look on the code changes and annotations I could find. As far as I see VDPAU-GL interop should be working on UVD2 and up, so Radeon HD4xxx should be able to run XBMC with hardware accelerated Video, which would be a nice plus. No warranty though....

                Comment


                • #28
                  Originally posted by spstarr View Post
                  Excuse me, but some of us have laptops and we can't just REMOVE THE GPU.... unless you want to pay to buy laptops for people.

                  Sure there are also non-mobile versions but for mobile users this is absolutely great!
                  you have a 7 year old laptop? I find it always funny how old is intel atom again? Maybe its their a hardware limitation but who cares if its the software or the hardware that fucks it up... there was also no vdpau or something equivalent for it. But hey intel is godness they make the best drivers for linux.

                  Of course if your hardware cant do nothing has very few features its easier to support this few features good.

                  And btw, whats this garbage with 32bit uefi in baytrail computers that hinders installing of every linux distribution...

                  Comment


                  • #29
                    Originally posted by brent View Post
                    VDPAU-GL interop is required for some software that implements custom video postprocessing or scaling, like XBMC or mpv. The interop API is based on fields, even for progressive content.
                    I couldn't find any info about fields and progressive video. Is it just a matter of naming (for progressive:field=frame), or do they actually interlace progressive content?
                    Regardless, this seems like it would only be an issue if you want to avoid copies. So, take two fields, deinterlace (using whatever method) to gl_texture->post-process->display (the universal planes/atomic pageflip could help to avoid a copy here).

                    Comment


                    • #30
                      Crossfire and a GUI

                      This is such great news! The to do list keeps getting smaller and smaller and smaller!

                      Now, if only they would prioritize Crossfire support and put together some sort of easy to use, updated configuration GUI, this driver would be perfect!

                      Comment

                      Working...
                      X