Announcement

Collapse
No announcement yet.

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

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

  • Following this thread for a while now...

    I've been following this thread for a while now and it seems to show both the best and worst of OSS. First, I think thanks are in order to gbeauchesne for doing the work. I personally am excited about getting some HW acceleration of video, although, I don't really need it with a okayish CPU and MB and no Blueray to play. It's a nice technical achievement, although my 9.10 64 bit Ubuntu on a HD4670 the colors are a bit off sometimes (green and red in particular)
    Second, Kano did a nice job IMHO with the mplayer-vaapi script. Thanks for that.

    On the whole NVIDIA vs AMD flamewar: come on guys, that's not necesarry. I feel the sentiment, that if you buy some hardware which doesn't work directly or as nice as under Windows, it might be a little frustating. Then again, new hardware and linux only play nice every now and then, and it has been like that for some time . The point being: if you desperately need something to work, buy something that has been shown to work and not the newest thing you can find. If you decide to buy new stuff and have problems.... well you knew that could happen, right?

    Comment


    • Well as i do no know of fglrx for something else than x86 then tell me what you think is so different?

      Comment


      • If you're of the opinion that programming for a pc (x86) is the same as, for example an embedded PPC, or microblaze or msp430, then I suggest you find some cheap devices and play around with them.

        Comment


        • Originally posted by Dewni View Post
          On the whole NVIDIA vs AMD flamewar: come on guys, that's not necesarry. I feel the sentiment, that if you buy some hardware which doesn't work directly or as nice as under Windows, it might be a little frustating. Then again, new hardware and linux only play nice every now and then, and it has been like that for some time . The point being: if you desperately need something to work, buy something that has been shown to work and not the newest thing you can find. If you decide to buy new stuff and have problems.... well you knew that could happen, right?
          You know, its funny.
          In the past, I've had *serious* trouble with ATI hardware, so I stuck exclusively with *anything but* ATI... had all kinds of crazy things (read TRIDENT) back in the day since the ATI drivers *never* worked on ANY platform. Once in a while, I got stuck with an ATI for one reason or another, and every time, it was a nightmare -- right up to the R300 IGP. So for my stuff, it was 3dfx (voodoo3-2000) back when they still existed -- worked like a dream (and that card is still in use and works great -- for what it is anyhow...), and then nvidia.

          But a funny thing... the nvidia experience wasn't without any bumps. There have been some nightmarish problems with their stuff too -- obscure hardware problems, driver problems, general lack of support.

          However, a major turning point was met when ATI got gobbled up by AMD. A neat thing is that even hardware that *NEVER* worked with ANYTHING slowly started coming in to shape -- that R300 IGP that was a previous cause of sleepless nights now works like a dream -- no tinkering required. And the way that R6xx drivers have shaped up... well my previous workhorse with an nvidia card has now been relegated to server-duty and my primary use-it machine is running with an RHD-3650 on open source drivers. And even with the currently in-development state of the drivers, it STILL is the best experience with a graphics card I've EVER had -- *just works* (at least for what I use it for... which is all that matters to me.)

          Now I'm guessing that the back and forth flamewars (both sides are guilty of) is due to a few factors;
          1) When someone makes a decision to acquire/use some particular thing, THEY THEMSELVES did so because they believe that their choice is the best. The unfortunate thing is that some people are very INSECURE and need constant reinforcement that they made the best choice, to the extent that they take OFFENCE when someone says something bad about their choice. It is, unfortunately, human nature. Another unfortunate thing is that what is the best choice for one person MAY NOT BE the best choice for someone else -- and this needs to be understood by those involved in the flame wars.
          2) One's experiences are affected by their experiences. There can be YEARS of bad (or good) experiences that can affect one's perceptions. My own personal bad experience with old ATI *junk* could have (and did in fact) keep me from using ATI hardware. However, it is hard to miss everything that has happened (and is still happening) on this front. I'm sure that I was, to some degree, influenced by very very *GOOD* experiences with AMD hardware, and so I decided to try a radeon GPU again (although this time with the understanding that it is a work in progress), and have, thus far, been extremely impressed. Perceptions have momentum, and it usually takes a LOT more positive energy to improve someone's perceptions than it takes negative energy to destroy it.

          The real cool thing for those interested in AMD Radeon GPUs is this; as you've mentioned, "new hardware and linux only play nice every now and then". Well from the *looks* of things (which really CAN change at a moment's notice), this situation seems to be improving drastically. There really is a lot of work that goes into building up the infrastructure that has been missing for quite a long time -- there were missing 3D drivers for R3xx-R5xx series, and for R6xx+, and the whole architecture was a mess, which means that there has been quite a bit of catch-up work going on and development of new cool stuff, like gallium3d. If (actually, lets say WHEN) the catch-up work is done and all the pieces are in place, I predict that it will be much easier/faster for new graphics hardware to be supported in a timely manner than it ever was before, i.e., the resources are spread out all over the place -- on multiple generations of hardware support, on infrastructure, etc., when all these pieces are in place, the same resources may go straight into support for new hardware, which has the potential to greatly accelerate support for new hardware. I *hope* that we can get to the point of having same-day support for new hardware in open source... and it most certainly *is possible*.

          Comment


          • Originally posted by mirv View Post
            ...programming for a pc (x86)...
            I think Kano was suggesting that fglrx was only available for x86.

            Now, if it's available for other architectures too, then I'm even more interested in a completely silent ARM/MIPS/etc + ATI GPU set-top device for my front room...

            Somehow though, I doubt if AMD will support all of the combinations of architectures that could be used for this job, so would only consider it for an OEM that might warrant the effort, e.g. Sony.

            Tim

            Comment


            • Originally posted by Kano View Post
              What's your definition of embedded? Basically it is a pc, it just does not look like one. xvba can be used with opengl output via xvba-video wrapper - that's nice to try, but it shows directly the limits.

              a) The only known driver is 9-10 with working OpenGL output - and that driver is definitely broken.
              b) OSD does only work without OpenGL output - but how to get that as long as the SDK is not available. Without OSD no subtiles are possible too - a very stupid restriction.

              On a standard pc there are more possibilities than in a bluray player - there it only has to decode mpeg2 (which is not possible with mplayer vaapi), vc1 (works most of the time) and h264 l4.1 (it works in maybe 70% of all cases at max).

              If you try other/non-standard h264 files then you can get everything from just rendering errors to complete driver lockup. That happended with vdpau too in the beginning, but now this is a really rare case. But compared even to the first vdpau enabled drivers it was much better than this 1 year old xvba!
              Compare apples to apples! you're comparing vdpau with xvba under a wrapper. what about limits and errors in the wrapper?

              I know it's not fair to SDS, but the crap we are seeing may be related to the wrapper, and not to xvba.
              Now I have to admit that fglrx is full of bugs, and all this crap could be related to fglrx only, but who knows???

              If you could get in your hands one of these mighty embedded systems that Bridgman speaks about, you could judge it, and compare it to vdpau.

              Comment


              • "Mighty" ?

                Comment


                • Was watching Californication with Va-api mplayer, when about half way through, it froze my desktop. While va-api patches seem to work, they are a bit unstable. Here's hoping things are quickly stabalized. There is some discussion about adding the VA-API patches over on the XBMC forums; however, they were complaining about the lack of good documentation.

                  Comment


                  • Originally posted by bridgman View Post
                    "Mighty" ?
                    Ops I meant "legendary", since I didn't read any name of those embedded.
                    Sorry for the mistake :-P :-) I use both (ironically) when making fun of my friends, and I used the wrong one

                    Comment


                    • Originally posted by gururise View Post
                      Was watching Californication with Va-api mplayer, when about half way through, it froze my desktop. While va-api patches seem to work, they are a bit unstable. Here's hoping things are quickly stabalized. There is some discussion about adding the VA-API patches over on the XBMC forums; however, they were complaining about the lack of good documentation.
                      For freezing you might have better luck turning compiz off before watching. Then you should be able to switch desktops and kill mplayer. The freezing seems to be a symptom of mplayer being in a sleep state.

                      Comment


                      • After looking back at the original Phoronix message announcing XvBA what's between the lines has become all to clear.

                        Quoted from http://www.phoronix.com/scan.php?pag...item&px=NjcwMA
                        "Word though has leaked onto the Internet by some Windows web-sites that AMD intends to provide high-definition video acceleration on some select Linux-based computers using ATI graphics."

                        With recent discussion in this thread it is now clear that those "select" computers are embedded systems and development will only occur to support the specific need of the specific embedded use. Since the only ones with access to the SDK are embedded dev's with very specific needs it is unlikely that we will ever see full support for the capabilities of UVD2 on proper PC's, IMO. My hope has now dwindled to a buggy and crippled implementation with little or no support for many of the features that the API is capable of ever being exposed to the larger user base.

                        As one who considers partial and gray statements the equivalent of deception, I feel rather foolish now. As a large part of my purchase decision was in hope of this long upcoming acceleration. Only to find that it was never intended for the bulk of end users, which was only now stated somewhat directly. As a long time crusader for ATI even in windows, I really hope for better to finally come to linux. Back to waiting on the OSS teams since the better will clearly not come from ATI.

                        I apologize that my first posts on this forum come off so negative, but I've been scouring the forums and trying separate fact from rumor for some time now. It seems that most of the statements that cut off with "NDA won't let me say anymore" are not to protect IP at all. But rather to feed the speculative rumor mill - which is a powerful, though deceptive, free marketing tool for ATI. From the attitudes I've seen on these forums I think many will agree.

                        Comment


                        • Originally posted by rjwaldren View Post
                          After looking back at the original Phoronix message announcing XvBA what's between the lines has become all to clear.

                          Quoted from http://www.phoronix.com/scan.php?pag...item&px=NjcwMA
                          "Word though has leaked onto the Internet by some Windows web-sites that AMD intends to provide high-definition video acceleration on some select Linux-based computers using ATI graphics."

                          With recent discussion in this thread it is now clear that those "select" computers are embedded systems and development will only occur to support the specific need of the specific embedded use. Since the only ones with access to the SDK are embedded dev's with very specific needs it is unlikely that we will ever see full support for the capabilities of UVD2 on proper PC's, IMO. My hope has now dwindled to a buggy and crippled implementation with little or no support for many of the features that the API is capable of ever being exposed to the larger user base.
                          Considering that we haven't actually *released* anything to the larger user base yet, it seems to be working pretty well

                          Right now OpenGL output offers the best playback quality with fglrx, so that's what the decode stack is using.

                          What functions do you think can not be performed using OpenGL ? The only one I can think of is DRM, and I'm sure you don't want that.

                          Originally posted by rjwaldren View Post
                          As one who considers partial and gray statements the equivalent of deception, I feel rather foolish now.
                          How do you consider silence ? With respect, it sounds like you are upset because we failed to deliver something that we never *said* we would deliver. This is why we don't talk about unannounced products & features.

                          Originally posted by rjwaldren View Post
                          As a large part of my purchase decision was in hope of this long upcoming acceleration. Only to find that it was never intended for the bulk of end users, which was only now stated somewhat directly.
                          We have been saying for a year or so that XvBA was developed for embedded markets. Honestly, this *really* should not be a surprise to anyone.

                          Originally posted by rjwaldren View Post
                          As a long time crusader for ATI even in windows, I really hope for better to finally come to linux. Back to waiting on the OSS teams since the better will clearly not come from ATI.
                          The only things we have *ever* said are :

                          - XvBA was implemented for use by closed-box embedded systems and proprietary player apps

                          - we expected to provide some form of decode acceleration to consumer PC users (not necessarily XvBA), probably in fglrx before the open source drivers

                          Originally posted by rjwaldren View Post
                          I apologize that my first posts on this forum come off so negative, but I've been scouring the forums and trying separate fact from rumor for some time now. It seems that most of the statements that cut off with "NDA won't let me say anymore" are not to protect IP at all. But rather to feed the speculative rumor mill - which is a powerful, though deceptive, free marketing tool for ATI. From the attitudes I've seen on these forums I think many will agree.
                          No, those statements mean exactly what they say; developers like Gwenole who are working under NDA try to help here, but if you grill them for internal details there'll be a point where they can't answer. NDAs are designed to "stop you just when things are getting interesting" because the "interesting" stuff is usually mixed in with the stuff we need to protect.
                          Last edited by bridgman; 11-12-2009, 07:14 PM.

                          Comment


                          • Bridgman thanks for the point by point response, I know it was a pretty annoying post.

                            I agree that GL video output, does work fairly well, but at the cost of CPU. I know the "modern CPU" argument, but when there's a piece of hardware on your graphics card, that is specifically capable of making the CPU irrelevant, but there's not a way to use it, it's easy to get raised expectations. I was at least under the impression that we would see broader and more complete coverage of the streams that UVD2 is capable of handling. I realize it's early but from statements made here it sound like the development will only be toward specific use cases as opposed to all that UVD2 is capable of. Hopefully I'm wrong with that impression.

                            The embedded question only became clear, when you directly said it in this thread in the past day or so. The articles on this site and the Wikipedia page don't say it, in fact they present it as requiring a 4000 series or later card and the proprietary ATI driver. They also present it at as direct replacement for XvMC and competitor to VPDAU as well as DxVA which certainly are not embedded only. I guess the error in these statements come from the fact that none of these are ATI statements, but rather statements by supposed insiders. Incidentally most of the in info out there points back to this site.

                            As far as the "silence" - You specifically are very good at relaying information without ambiguity but there are others here that seem to enjoy it. So, yeah, there are some posts were I wish the beta team member that wants to play "I know something you don't know" would not say anything at all.

                            Comment


                            • Little strings exercise:

                              Used functions in /usr/lib/va/drivers/xvba_drv_video.so:

                              XVBACreateContext
                              XVBACreateDecode
                              XVBACreateDecodeBuffers
                              XVBACreateGLSharedSurface
                              XVBACreateSurface
                              XVBADecodePicture
                              XVBADestroyContext
                              XVBADestroyDecode
                              XVBADestroyDecodeBuffers
                              XVBADestroySurface
                              XVBAEndDecodePicture
                              XVBAGetCapDecode
                              XVBAGetSessionInfo
                              XVBAGetSurface
                              XVBAStartDecodePicture
                              XVBASyncSurface
                              XVBATransferSurface
                              XVBAUpdateSurface

                              Those strings are also in /usr/lib/libAMDXvBA.so.1.0 and seem to be used. When you would think that all XVBA prefixed functions are exported then 2 are still unused:

                              XVBAGetSurfaceCap
                              XVBAQueryExtensionEx

                              If somebody would use a real good debugger maybe headers could be generated out of the binary too. But at least the function calls should be known...

                              And some extra PCOM functions...

                              PCOMBeginFrame
                              PCOMCreate
                              PCOMDestroy
                              PCOMEndFrame
                              PCOMExecute
                              PCOMGetCapsEx
                              PCOMPresent
                              PCOMResetQueue

                              And something with BluRay in the name in MCOM functions:

                              MCOMBluRayDecodeStreamCaps
                              MCOMCreateEx
                              MCOMDestroy

                              Lots of things must be hidden there
                              Last edited by Kano; 11-12-2009, 10:06 PM.

                              Comment


                              • Originally posted by rjwaldren View Post
                                Bridgman thanks for the point by point response, I know it was a pretty annoying post.

                                I agree that GL video output, does work fairly well, but at the cost of CPU. I know the "modern CPU" argument, but when there's a piece of hardware on your graphics card, that is specifically capable of making the CPU irrelevant, but there's not a way to use it, it's easy to get raised expectations. I was at least under the impression that we would see broader and more complete coverage of the streams that UVD2 is capable of handling. I realize it's early but from statements made here it sound like the development will only be toward specific use cases as opposed to all that UVD2 is capable of. Hopefully I'm wrong with that impression.
                                I'm glad you posted more details; I may be able to ease your mind a bit.

                                We normally describe the video playback stack in two parts; decode, and render (or presentation). Decode goes from a bitstream representation to some kind of YCbCr image in the video's native resolution - render/presentation goes from that image to a filtered RGB image in the resolution you want on the screen. The UVD only handles decode functions; everything else is done in shaders anyways.

                                There are a variety of acceleration APIs available for doing the render operations, including OpenGL, Xv, the bottom end of VA-API and VDPAU, a variety of proprietary APIs, or software rendering to an X11 surface. Other than software rendering, they all use roughly the same amount of CPU, although OpenGL will tend to use a bit more because there is some general purpose code between the API call and the shader invocation. The difference is pretty small though.

                                The important point here is that you are not "leaving hardware capability unused" - UVD goes from H.264/VC-1 bitstream to YCbCr native resolution, and does IDCT/MC processing for MPEG2. That's all it does on any OS. I believe the same is true for our competitors hardware as well.

                                I made a long post a few months ago showing the entire stack; will see if I can find that and link to it here.

                                Originally posted by rjwaldren View Post
                                The embedded question only became clear, when you directly said it in this thread in the past day or so. The articles on this site and the Wikipedia page don't say it, in fact they present it as requiring a 4000 series or later card and the proprietary ATI driver. They also present it at as direct replacement for XvMC and competitor to VPDAU as well as DxVA which certainly are not embedded only. I guess the error in these statements come from the fact that none of these are ATI statements, but rather statements by supposed insiders. Incidentally most of the in info out there points back to this site.
                                AFAIK the articles came from some good old fashioned investigative reporting (picking through the binaries, calling around to dig up bits of leaked information, putting the bits together into an overall picture..), and they're pretty close. What they missed was that we were targetting the sealed-box embedded market at the time, not general consumer use.

                                Originally posted by rjwaldren View Post
                                As far as the "silence" - You specifically are very good at relaying information without ambiguity but there are others here that seem to enjoy it. So, yeah, there are some posts were I wish the beta team member that wants to play "I know something you don't know" would not say anything at all.
                                Have some sympathy for the devs working under NDA. They usually start talking about safe things and trying to help, then get herded towards areas they are not allowed to discuss. I really believe that if people here didn't beat on them for more details then you wouldn't see the "I can't tell you" responses.
                                Last edited by bridgman; 11-12-2009, 10:07 PM.

                                Comment

                                Working...
                                X