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

[Hans]

LOL but really lol. You probably have not looked at the current situation closer... On the other hand, it's better to start the day laughing rather than crying. Thanks.

Enlighten me please. I am not seeing any proper linux support from nvidia neither. Oh yes, their binary blob is kinda good. But thats only because of their shared codebase with windows. Well fglrx uses the "same" kind of shared codebase, but they also got the oss drivers.

[Kano]

Do you REALLY want to buy a CURRENT gaming card or a htpc card and use OSS drivers? That does not make much sense if you don't want to dual boot all the time. OSS drivers are a long term invest, for those who think gfx cards will last forever (or at least very long). That may be interesting for old AGP cards as you can not buy newer PCI-E cards for old boards, but since PCI-E you can easyly replace cards without exchangeing the rest. So gfx cards are no longer critical - maybe when the bus changes again.

[Kano]

I do not intent to BUY gfx cards at all. But when i got one ATI card then i use fglrx and not oss just for testing xvba/vaapi. As i try to support Kanotix users best fglrx the first choice, it is more or less impossible to backport more than oss ddx drivers. I test it to find - and possible fix issues. With Kanotix Excalibur and .28 kernel (installable in the repo) you still can run fglrx with R300-R500 too. For xvba/vaapi testing i use a 4550 - you can be sure i did NOT buy it. As soon as i got a GT 220 i put the 4550 in a 2nd system that i only use for testing. All hd content i usually watch with a GT 220 since then. Currently it does not matter if you use vdpau or vaapi over vdpau-video wrapper anymore (when you use the scripts mentioned above). But for ATI you must be lucky when you see anything. OpenGL rendering with forced vsync is a must however. xv is unusable and no fglrx DEV told me a good reason why it was never improved. I dont like bridgmen's marketing speak about this issue. If xv is the holy grail for you then stick with oss - but that does not even work for hd 5.

[bridgman]

The term "marketing speak" often implies that I'm somehow misleading you or trying to make things sound better than they are. Don't think I'm doing that.

I am saying that in general marketing sets priorities for engineering development, and that in the last year or so those priorities have put other things ahead of improving Xv - although none of us expect that to be the case forever. I am also saying that today users will get better results with fglrx by using GL output rather than by using Xv.

Is that what you mean by "marketing speak" ?

[Kano]

Is it impossible for the fglrx team to take the time to fix xv to the same level the oss driver already provides up to hd 4? A big dark cloud comes up over the competence of those devs. Even when fglrx is for workstations first xv is the most common usage case for videos - even for commericial apps which will NEVER work correctly as they don't allow opengl playback. When you see the bad performance of hd 5 cards with xvba you really should consider working on it. Also h264 > l5.1 is very common and should work. When you think that even mobile systems with psb could decode hd content better than ati then somebody should begin improving it. Even intel works on it, slowly but they work - but then even fully opensource. mpeg2 support was first, tested that already, but i could not test the new h264 vaapi support due to missing test system. ATI is falling even more behind others concerning video playback - binary AND oss. Maybe you don't see that with your pink ATI glasses - at least you have got a little excuse that you work for em compared to Q.

[bridgman]

OK, let me ask the question again. Are you saying that the devs should disobey their management and work on Xv *instead* of delivering the features, fixes and new product support they have been assigned ? It's not a question of "slipping in a bug fix one afternoon" - I'm sure that would have already happened. The video driver stack needs some additional infrastructure to support sync-to-vblank with Xv; it's not a quick task.

I understand that from your perspective video functionality is more important than some of the other features the devs work on, but in fairness we do have other customers and we do have to deliver features that *they* want as well. As the devs work through the higher priority tasks I think you'll see more work on video functionality happening, but I have said this all multiple times in the last couple of weeks and I don't feel that the message is getting through.

I don't understand the reference to Intel. They don't make discrete GPU products today and don't compete in the workstation merket, so the scenarios their marketing groups consider will be primarily consumer ones (similar to what you are looking for).

[Kano]

@bridgman

I follow the driver "improvements" since years. You would not even notice if the full fglrx team would just increase the version number and do nothing for 1 month. Why should they work on something usefull in their free time? Of course the management focus has to set priorites, but why not on something more usefull for customers? Instead of releaseing 12 unfinished drivers better focus on fixing em and release less but working ones.

The intel reference is easy to understand when you think of 08/15 desktop systems. In my definition they do not use dedicated gfx cards only onboard/onchip solutions to save money. Compare the performance of iX with Phenom II with onboard ati. Some users just don't play games but like to watch videos. But compared to ATI you see already h264 decoding there in the oss drivers (should be possible with older G45 later this year).

If you go to your beloved embedded oem market then intel has the psb chips with the powervr core. Those drivers are not opensource and only work with some xservers which i do not call optimal, but at least you could create working oem solutions with Linux base. Where are your famous oem embedded users which do that using Linux not Win embedded?

@Q

You can be sure i don't use fully outdated systems - i really compile much. But using cpu decode on hd video is not usefull - same for using opencl for it. opencl would use the normal gfx core but NOT the dedicated chip which is already in there. Do you call that good? I don't. The combined power consumption will be always higher than using the right chip for that. That's similar when you use oss drivers for normal work which do not use powermanagement. You might "feel" better not using the bad binary stack, but basically you need much more energy than you would with another driver - especially on the mid/highend cards. So the only one how laughs in your energy provider - you have to pay the bill, don't forget. Ok the latest highend nv fermi have too high idle consumption, but what you propose using is definitely not better.

[bridgman]

I follow the driver "improvements" since years. You would not even notice if the full fglrx team would just increase the version number and do nothing for 1 month. Why should they work on something usefull in their free time? Of course the management focus has to set priorites, but why not on something more usefull for customers?

They are working on things that are more useful for customers - just not more useful for *you*. Again, we *do* have other customers and we *do* sell into the workstation market, which continues to be the largest single segment of the Linux client PC business.

Instead of releaseing 12 unfinished drivers better focus on fixing em and release less but working ones.

Um... so how are we supposed to deliver bug fixes and new hardware support - just sit on the changes until we have new video features to go along with them ?

The intel reference is easy to understand when you think of 08/15 desktop systems. In my definition they do not use dedicated gfx cards only onboard/onchip solutions to save money. Compare the performance of iX with Phenom II with onboard ati. Some users just don't play games but like to watch videos. But compared to ATI you see already h264 decoding there in the oss drivers (should be possible with older G45 later this year).

My question was how the Intel reference is relevent when they don't compete in the workstation market and therefore their marketing priorities won't include workstation features & functionality ?

If you go to your beloved embedded oem market then intel has the psb chips with the powervr core. Those drivers are not opensource and only work with some xservers which i do not call optimal, but at least you could create working oem solutions with Linux base. Where are your famous oem embedded users which do that using Linux not Win embedded?

I'm pretty sure we were talking about workstation, not embedded...

(checks previous post)

Yep, I said workstation, not embedded.

[monraaf]

I understand that from your perspective video functionality is more important than some of the other features the devs work on, but in fairness we do have other customers and we do have to deliver features that *they* want as well.

In all fairness the Catalyst release notes mention three distributions that are supported.

• Red Hat Enterprise Linux suite
• Novell/SuSE product suite
• Ubuntu

Arguably Ubuntu is more oriented to the home user, and Ubuntu users are more likely to use their OS to watch videos. The default and only officially supported video player for Ubuntu is Totem using the GStreamer framework. There are no GStreamer GL output plugins in the Ubuntu repositories, so users have a choice to either watch videos with tearing or install an unsupported player and use GL output. Hardly an ideal situation for an OS that's supposed to be supported by Catalyst.

But if adding vsync for Xv to Catalyst is a too daunting task, I'm sure the GStreamer developers welcome any GL/XvBA patches from ATI/AMD.

[Kano]

First of all you have to compare the ATI 5870 to GTX 480 and 5850 to GTX 470. Also there is huge difference when you only use 1 display and not 2. A GT220 beats a 4550 easyly, so better compare that to your lowend cards.

Also i prefer to use desktop systems - those have got only 1 cpu. Server systems with more than 1 cpu - in your case 4 must be loud as hell - currently i prefer to use a relatively low noise Esprimo system with E8400 cpu for everyday use, a Q930 for testing ATI and X3380 for compiling kernels and gaming (only rarely). I have got no need for multi cpu systems at all at home as i am not deaf - as you must be. The main target for my systems is low noise until you need pure power, then it can be a bit louder. Therefore powermanagement has to work for CPU and GPU.