I was also curious about that sentence. And I share the same sentiment (though not to the same extent) about all the hush-hush in articles I read on this site. It does get kind of old seeing "well, we can't talk about that just yet" or "now we'll speak up" and things of that nature.
But, as a linux user with an R500, it's either dig through mailing lists, press releases, and IRC logs or put up with Phoronix's occasional secrecy. Laziness wins out.
If the spechs for the antifunctions where known you could actualy write drivers that makes things that "just works".
AIK UVD2 will be supported in the future.
But XVMC would be an very welcome gesture for UVD, even with the usual ATI tearing ;D
There is an thread where video acc and antifunctions are discussed.
How about VAAPI? Intel is going to support it (already does on some ATOM chipsets I understood), if AMD would support it as well I guess ffmpeg support wouldn't be far away and that would bring support to mplayer, xine etc. And at that point nVidia won't really have any choice.What will be interesting though is how AMD decides to implement their high-definition video support on Linux. Seeing as there is no suitable standard right now, they will likely introduce their own interface.
ATM there is no standard to accelerate h.264 (XvMC only supports MPEG2), VAAPI should be it but seems not to be used..
That freedesktop article says:
So I do not believe Intel works on extending XvMC.The main motivation for this proposal is to enable hardware accelerated video decode at various entry-points (VLD, IDCT, Motion Compensation etc.) for the prevailing coding standards today (MPEG-2, MPEG-4 ASP/H.263, MPEG-4 AVC/H.264, and VC-1/VMW3). Extending XvMC was considered, but due to its original design for MPEG-2 MotionComp only, it made more sense to design an interface from scratch that can fully expose the video decode capabilities in today's GPUs.
Intel - Jonathon Bian is the prime contact for VAAPI - http://freedesktop.org/wiki/Software/vaapi
I don't know the interplay between them, but it looks like Jonathon was one of the original authors of the i810 driver and Keith is the new kid on the block (Intel driver wise).
But it is clear that *BOTH* efforts are being funded by Intel, and *BOTH* seem to want to ignore the other. A Wiki article is hardly ever authoratitive or accurate .
My position in this has been very consistent -- "I don't know yet"
Once we get 6xx/7xx 3D engine info released to the public and (hopefully) some basic power management stuff, video is next on the list for us to look at. Right now I have high confidence that IDCT (HD3xxx and earlier) will be released, low confidence that UVD (HD2xxx/HD3xxx) will be released, and slightly higher confidence that UVD2 (rs780, HD4xxx) will be released -- but won't be sure on any of them until we go through the risk & IP analysis effort.
Whether support for that hardware is implemented with XvMC or VAAPI or something else is up to the community. If our developers implemented the support first we would probably go with XvMC and try to align extensions with Intel to make things easier for player developers.
Use of video acceleration hardware by the proprietary driver is a different story -- we have a bit more freedom to use the hardware in fglrx without the associated IP hassles, but only to the extent that we can discourage reverse engineering or at least publication (say, in an open source driver) of the resulting information.
Brig Bridgman, I'm not really sure from an IP/ DRM perspective that supporting video decode in the Linux Catalyst is any riskier than in the Windows version. I'm guessing that it's probably not much harder for a determined hacker to RE the Windows version