ATI, please release an Open UVD API

[droidhacker]

Or you could always do what I did... buy a broadcom bcm970015, which is a video decoder with OPEN SOURCE DRIVERS and fully redistributable firmware -- to the point that the whole works as is in Fedora (970015 support comes in F14 to be released in a few days), not even the need to add in weird repos. Lets you have that out-of-the-box *EVERYTHING* experience. And at less than 1 watt....

Now if only the post office would hurry up with it...


The big question I have is this;
How is it that broadcom, typically known for being tough to deal with in open source, is able to provide the source code for this device (which supports all that DRM nonsense on the windoze side of things), but AMD, known for being a happy player in the world of open source, is not able to provide the similar code for their implementation of virtually the exact same thing?

[markg85]

About the subject: I'd prefer to have a proprietary yet functional UVD API with H264, VC-1 and MPEG-2 decoding, (similar to what nVidia actually provides us (with VDPAU)) than an Open-Source implementation that could be risky to be implemented, due to patent infringing (personally, I hate patents). So, I think the best way to provide us an "Open UVD API", would be, instead of releasing the UVD API to the open-source community, use the graphics card shader capabilities to decode H264, VC-1, MPEG-2 formats on hardware...
Cheers

Imho it's (for the moment) fine if they released an Open API, but closed source. So that would end up in a freely available header file and a binary "XvBA" .so file that is tied to the fglrx driver. Yes, it's not perfect for "fully open source minded poeple" (me included) but it's better then the current state and still allows AMD to close whatever the hell they want to close.

As for the argument (from AMD, not you) that it would be to easy to reverse engineer it i say that's a non argument since we already have the current XvBA somewhat working implementation which is using the exact same functions from the core XvBA lib that AMD tries to protect so much so WHY isn't the API documentation released yet? You don't need to provide UVD specifics! just the XvBA usage docs.

Note: AMD already has released XvBA since it's in every catalyst driver since.. some time. All they just didn't release yet are the function names and the header to make use of it.

While looking at the file : libXvBAW.so.1.0
with the ldd command (to find which libraries it links to) it's neat to see that it's not relying on a single AMD lib!:

linux-vdso.so.1 => (0x00007fff39fab000)
libm.so.6 => /lib/libm.so.6 (0x00007f4032fbb000)
librt.so.1 => /lib/librt.so.1 (0x00007f4032db3000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f4032b3d000)
libc.so.6 => /lib/libc.so.6 (0x00007f40327e0000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f40325c3000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f40323b0000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007f40321ae000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f4031fa9000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00007f4031da3000)
libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0x00007f4031ba2000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f4031865000)
libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0x00007f4031650000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f4031435000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007f403122a000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f4031025000)
/lib/ld-linux-x86-64.so.2 (0x00007f4033619000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f4030e23000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f4030c1d000)

So, i bet that you can access the UVD chip if you just know how to access it using that lib. And i bet this is the function you need for that:

00000000000d4120 T UVDCommand::Initialize(Device const*)

(found with the command: nm --special-syms -D -C libAMDXvBA.so.1.0) Sadly the XvBA function didn't spit out their required arguments:

00000000000e9a20 T XVBACreateContext
00000000000eb360 T XVBACreateDecode
00000000000eaff0 T XVBACreateDecodeBuffers
00000000000ec150 T XVBACreateGLSharedSurface
00000000000e9ce0 T XVBACreateSurface
00000000000eb680 T XVBADecodePicture
00000000000e9b80 T XVBADestroyContext
00000000000eb590 T XVBADestroyDecode
00000000000eb150 T XVBADestroyDecodeBuffers
00000000000e9eb0 T XVBADestroySurface
00000000000eb740 T XVBAEndDecodePicture
00000000000eb210 T XVBAGetCapDecode
00000000000e9bb0 T XVBAGetSessionInfo
00000000000ea570 T XVBAGetSurface
00000000002b7f20 D XVBAGetSurfaceCap
00000000000e9a00 T XVBAQueryExtensionEx
00000000000eb5c0 T XVBAStartDecodePicture
00000000000e9ee0 T XVBASyncSurface
00000000000eac70 T XVBATransferSurface
00000000000ea070 T XVBAUpdateSurface

And interesting while browsing through the libAMDXvBA.so.1.0 is a bunch of new functions for the 6xxx series (i see a lot of barts* functions. But what's even more wanted here now is the advanced deinterlacing:

MotionAdaptiveDeinterlacingFilter::MotionAdaptiveD einterlacingFilter

So the neat deinterlacing IS in the XvBA API!

If someone that's a bit more knowledgeable then me regarding pulling a .so file apart, please do so! I do seriously wonder if it's possible to reconstruct the header file.. I haven't found anything yet.

The thing that pains me in this is that all the functions are there to give perfect hardware accelerated video decoding and even a range of different deinterlacing methods are there! All we need is the information to make use of these functions.

i'm guessing gbeauche and bridgman are under strict NDA rules here and can't say a thing?

[bridgman]

i'm guessing gbeauche and bridgman are under strict NDA rules here and can't say a thing?

We can say all kinds of things. Just not about this

We have been working on opening up the XvBA API (at least the PC-oriented version that uses OpenGL for the backend) and I think we are getting fairly close.

[Jimbo]

As you say... RUMORS!!!

Intel graphics are a massive turd, don't be expecting them to suddenly make something that's actually mediocre -- mediocre is far better than intel.

Anandtech had a preview of a sandy bridge chip on august, keep in mind that this is not final hardware, but I guess the hardware is not going to change much, and there are not final drivers.

http://www.anandtech.com/show/3871/the-sandy-bridge-preview-three-wins-in-a-row/7

For video acceleration part, the previous gpu integrated on core i5-i3, intel HD, has support on linux for mpeg2 and h264.

[gbeauche]

We have been working on opening up the XvBA API (at least the PC-oriented version that uses OpenGL for the backend) and I think we are getting fairly close.

I doubt it as there are still two API design flaws that prevent it from being useful without using awful workarounds (or luck).

[gbeauche]

About the subject: I'd prefer to have a proprietary yet functional UVD API with H264, VC-1 and MPEG-2 decoding, (similar to what nVidia actually provides us (with VDPAU)) than an Open-Source implementation that could be risky to be implemented, due to patent infringing (personally, I hate patents). So, I think the best way to provide us an "Open UVD API", would be, instead of releasing the UVD API to the open-source community, use the graphics card shader capabilities to decode H264, VC-1, MPEG-2 formats on hardware...

I am sorry but those two sentences contradict themselves. Note that the very reason why Fedora people didn't want to include libva initially was because it did contain an Open Source driver (G45) for MPEG-2 and H.264 using shaders (+ BSD for the later). And thus, was suggested to be a potential risk vs. patents. Debian people didn't seem to have similar concerns though.

[gbeauche]

So the neat deinterlacing IS in the XvBA API!

No, it's not. Those functions are mid to low-level and shared verbatim with the Windows components. However, they are not exposed to XvBA API.

If someone that's a bit more knowledgeable then me regarding pulling a .so file apart, please do so! I do seriously wonder if it's possible to reconstruct the header file.. I haven't found anything yet.

You can try but good luck! Have fun. If you know how depressive I can be with that pile of "stuff" with the API in hands...

[droidhacker]

Anandtech had a preview of a sandy bridge chip on august, keep in mind that this is not final hardware, but I guess the hardware is not going to change much, and there are not final drivers.

http://www.anandtech.com/show/3871/the-sandy-bridge-preview-three-wins-in-a-row/7

For video acceleration part, the previous gpu integrated on core i5-i3, intel HD, has support on linux for mpeg2 and h264.

DO NOT bother trying to prove any kind of point using benchmarks. Benchmarks can be made to prove anything. I can give you benchmarks showing an 8086 blowing the doors off an i7. Totally meaningless.

[Jimbo]

Of course, I better trust your word than anandtech.

[markg85]

droidhacker and jimbo please go back on topic.
Thanx.