If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

XvBA on Evergreen

06-25-2010, 11:55 AM

There was an active discussion about this going on in an NVidia forum; figure we should probably move it back to the ATI/AMD forum so everyone can find it easily.

Current status in a nutshell is that our internal testing (which focuses on the NDA version of the API) indicates that XvBA is working on Evergreen, while end user experience (using gbeauche's VA-API adapter) is that Evergreen support does not work. The problem seems to be related to a specific function call used when running XvBA decode with GL output, which gbeauche apparently identified some time ago.

I don't know if the problem has been reproduced in the multimedia driver team; will try to chase that down next week.

Comment

I verified the same using ATI 4550 (xvba works up to h264 l4.1) and ATI 5670 (xvba always shows crap). It is really annoying when the "internal" tests are made with an interface that's not useable for end users. Why is it so critial to hide some header files? Nv does not have this problem also vdpau works with h264 l5.1 too (when you use properly patched ffmpeg also divx) - also xvba does not have mpeg2 VLD accelleration. It is very hard to recommend ATI for a Linux htpc because when you leave the supported mplayer vaapi path you only see problems. xbmc can at max show videos with size % 16 = 0 which is usually never true for 1080p. vlc shows just green. You can not blame the app devs for those issues when the driver has too many problems. ATI has to work on those issues because just providing OpenGL 4 for cheaper cards is not enough. When you consider how long those issues are known and the only problem that was fixed was a color change problem with h264 material (with 10-5 driver) which existed since the first public xvba-video wrapper was available (9-10) then this says all.

Comment

I'd say you're being too kind, Kano. I've always rooted for AMD, although i'm not as huge a fanboy as some, and even I can't think of any scenario where I would actually recommend an ATI card for a linux HTPC. I'd have to say go Nvidia or else get Windows, because the XvBA situation on linux just isn't working and there's no sign it's going to get any better. At least with other fglrx issues AMD seems to at least be working on them and there's hope that things will improve.

Even on Windows, ATI seems very limited in what they do with VA compared to NVidia. Check out the recent VLC 1.1 release which ATI doesn't work with because they need access to some magic GUID to enable getting the video output back to the application. I don't know if ATI's hardware design just doesn't allow them to share any information or what - it's strange to think that NVidia's lawyers/decision makers are more willing to be open than AMD's but that appears to be the case with video.

Comment

Above me the idea to let ATI just "give" the required headers is, yet again, posted. I don't think that's a good idea.

You see, that other user on these forums here that made the XvBA VA-API backend has the required ATI docs/headers under NDA so you would think that he would be able to make a good XvBA VA-API driver right? Well, wrong. As he said on some post here there is a BUG in the implementation of the header file -- which is not released by ATI, not even under NDA if i'm right -- thus that poor user can't fix a thing.

So, to cut a long story short. The headers are useless if the header implementation, the source, contains bugs. This is where ATI is needed to fix the source files. That user even pointed out to bridgman which function (in a hint) needs to be fixed so ATI should no where to look and just fix it.

As for testing. I don't know how ATI tests this stuff or opengl 4 stuff but something is obviously wrong here since XvBA is broken on 5xxx cards and opengl 4 tesselation is (on windows, not tested on linux) still heavily corrupted.. something a simple visual test done by a HUMAN would heve been detected.

Comment

Huh ? I don't think anyone said anything about a bug in the header file. What gbeauche was saying was that there was a bug in one specific API function in the driver.

The testing issue seems to be that XvBA itself is working but there's a problem with the GL render output after XvBA has finished decoding the frame. The GL render path is something we added for consumer use and have not released yet.

Most of the testing focus is using the NDA-only render path developed for ISVs shipping binary player apps, and it looks like there's not enough testing on the GL output path.