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

[timmydog]

...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

[Vighy]

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.

[bridgman]

"Mighty" ?

[gururise]

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.

[Vighy]

"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

[xzero2]

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.

[rjwaldren]

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.

[bridgman]

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.

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.

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.

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

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.

[rjwaldren]

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.

[Kano]

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