VDPAU vs. XvMC? [Archive] - Phoronix Forums

amphigory

10-24-2009, 11:34 AM

I'm curious which direction the OSS drivers will be going regarding video acceleration. From the Radeon feature list it would appear XvMC would be implemented, but from the latest Phoronix news (VDPAU via Gallium3D) and a post on lists.freedesktop.org from mostawesomedude it would appear VDPAU would be the preferred API.

http://xorg.freedesktop.org/wiki/RadeonFeature

http://www.phoronix.com/scan.php?page=news_item&px=NzYzNg

http://lists.freedesktop.org/archives/xorg/2009-August/047047.html
I don't feel like digging through emails and writing point-by-point
replies, so I'm just going to do point-by-point talking-to-myself.

- The APIs for accelerating full decoding and not just colorspace
conversion and scaling (Xv) are:
-- VA-API
-- VDPAU
-- XvBA
-- XvMC

Of those, only VDPAU is worth implementing. XvMC can be done in terms of
VDPAU if you're creative enough.

- OpenCL would be fine for video, but stupid and slow, just like
OpenGL-based video decoding.

- The current plan is to *not* add any more video decoding to any DDX,
but to do it in Gallium using a state tracker. Expand g3dvl to be a true
pipeline, let drivers fill in the pipeline with whatever they can
accelerate, and then expose VDPAU and XvMC to userspace. Of course, only
radeon (me, MrCooper) and nouveau (marcheu, ymanton) have actually
agreed that this is a good idea, but the intel devs will probably keep
maintaining their XvMC and VA-API implementation either way.

- It's not done because we've been working on other things. If it makes
you feel better, 3D support *is* required for this kind of work, since
we don't have documentation on the dedicated video decoders onboard most
GPUs, and we haven't reverse-engineered them, so we'll have to use 3D
shaders instead.

TechMage89

10-24-2009, 05:42 PM

That's the latest news as far as I know.

The bottom line is that anything above mpeg-2 mc on XvMC is kind of a hack.

The Intel driver guys have created VAAPI, but it hasn't shown much adoption.

NVIDIA has created VDPAU, which is supposed to work quite well, and NVIDIA is really pushing for wide adoption of the API.

ATI has something called XvBA, but they're not willing to say anything about it yet.

Open-source drivers haven't had much in the way of video-decode accel implemented (except for Intel), because devs have been busy getting 3D and gallium stuff working.

xiando

10-28-2009, 07:23 PM

Open-source drivers haven't had much in the way of video-decode accel implemented (except for Intel), because devs have been busy getting 3D and gallium stuff working.

This is a good thing, IMHO. The radeon driver didn't even have the occlusion query support (http://cgit.freedesktop.org/mesa/mesa/commit/?id=660acd60d00366c97fbe7caf3995a75ce935a19b) before today. Modern CPUs use so little percent of their power to decode video anyway, so I hope video hardware acceleration does not become a high priority before we get more basic things like OpenGL 2.0 (at minimum).

Don't get me wrong, hardware x264 decoding would be cool, but there are more important things I would rather have. My box has no trouble at all running a HD adult movie on both of my monitors at the same time, but a few of kwin's more fancy effects simply do not work at this point (most do, however) and I hope that gets higher priority.

pingufunkybeat

10-28-2009, 07:31 PM

Modern CPUs use so little percent of their power to decode video anyway
Full HD stuff can still clog up a full core of a really powerful processor.

Multi-threading helps there, but it's still not a small percentage of processor power being used.

It's a shame to have dedicated hardware that can decode the stuff faster, with 100x less power and CPU load, and not being able to use it.

But yeah, I also find power saving and reasonable 3D to be far more important at this point.

amphigory

10-28-2009, 08:10 PM

Oh I think 3D and power management are more important as well. I was curious whether XvMC or VDPAU was the API to be implemented. It would seem to be a waste of time implementing XvMC.

This is a good thing, IMHO. The radeon driver didn't even have the occlusion query support (http://cgit.freedesktop.org/mesa/mesa/commit/?id=660acd60d00366c97fbe7caf3995a75ce935a19b) before today. Modern CPUs use so little percent of their power to decode vidteo anyway, so I hope video hardware acceleration does not become a high priority before we get more basic things like OpenGL 2.0 (at minimum).

Don't get me wrong, hardware x264 decoding would be cool, but there are more important things I would rather have. My box has no trouble at all running a HD adult movie on both of my monitors at the same time, but a few of kwin's more fancy effects simply do not work at this point (most do, however) and I hope that gets higher priority. Erm... not everyone is using their video card for desktop effects. I have a quad core (Q6600) box running MythTV as my DVR (Firewire capture --> Myth --> 1080p LCD panel). I'm using a RV620 video card and there are issues rendering HD video to a 1080p panel using proprietary AMD driver. RV620 should be sufficient for clean HD rendering. I will probably give the OSS drivers a try sometime within the next week.

highlandsun

10-29-2009, 03:53 PM

Full HD stuff can still clog up a full core of a really powerful processor.

Multi-threading helps there, but it's still not a small percentage of processor power being used.

It's a shame to have dedicated hardware that can decode the stuff faster, with 100x less power and CPU load, and not being able to use it.

But yeah, I also find power saving and reasonable 3D to be far more important at this point.

Agreed up to the last point. I don't care about 3D at all, but I watch videos pretty often on my laptop, and it's annoying that the CPU heats up and makes the fan spinup louder due to the load. Power saving would be good too, but it still strikes me that more computer users watch videos than play games. And ultimately it's about efficiency; if I can offload a bunch of processing to the GPU that keeps the CPU free to be 100% responsive to do other things. How can you possibly not want that?

pingufunkybeat

10-29-2009, 05:12 PM

Just to clear this up: Of course I want it.

It's just that it's not as big a deal on my quad-core desktop computer as it would be on a laptop.

So for me, powersaving and 3D are more important. I'm not much of a gamer, but I can watch HD videos right now, and I can't use all of the 3D capability of my card.

bridgman

10-29-2009, 05:20 PM

This is one of those cases where desired priorities don't make much difference -- the development sequence is based on architectural hierarchy :

- dynamic power management will be built on top of kernel modesetting, and decode acceleration will be built on top of Gallium3D drivers.

- Gallium3D drivers, in turn, depend on DRI2 and can leverage most of the code (and nearly all of the painful lessons) from the 3D work done on the classic Mesa 3D drivers

- DRI2 depends on memory management, and the memory management work was driven primarily by kernel modesetting

Completion of new functionality pretty much *has* to follow that dependency tree, no matter what order the work is started. Resistance is futile.

I updated the chart at the end of the RadeonFeature page to make this a bit more clear :

http://www.x.org/wiki/RadeonFeature

popper

10-29-2009, 07:51 PM

and then we have that pesky LONG Standing lack of 'UVD ASIC Video decoder' documentation delivery problem OC bridgeman...

that lack of delivery solution would, and still does as always sit above all the others in the architectural hierarchy.

just thought id pop that in, looking at todays date ,review time questions and all that soon :)

incase others are wondering what thats all about, your average AMD/ATI chip today, and for a very long time now, has had that fully working and powered UVD ASIC hardware decoding chip intigrated onboard (its the eq of , but we are told better than the Nvidia ASIC HW VDPAU Decoder).

but you cant use it, as noone in the OSS development fields across the world knows how to program this 'UVD' or make and so submit patches for its use in FFmpeg/x264 Decoding/Encoding etc, Yet... if ever.

energyman

10-29-2009, 08:21 PM

Powerplay 'mostly'?

Does.. . does that mean I can try the free driver without being killed by the fan on my 3870?

bridgman

10-29-2009, 08:41 PM

and then we have that pesky LONG Standing lack of 'UVD ASIC Video decoder' documentation delivery problem OC bridgeman..

One more time, the open source graphics plan does *not* include UVD programming information. This is *not* a "delivery problem".

I have committed to investigate whether UVD can be added to the plan once we have finished the planned work. That's it.

amphigory

10-29-2009, 11:41 PM

Thanks for the updated picture of the driver stack. Resistance is futile, indeed.

xiando

10-30-2009, 12:55 AM

One more time, the open source graphics plan does *not* include UVD programming information. This is *not* a "delivery problem".

I have committed to investigate whether UVD can be added to the plan once we have finished the planned work. That's it.

This indicates that the secret AMD total plan for AMD World Order is flawed.

That the AMD apparently does NOT want me or my family to have access to the UVD programming information is a serious problem, I have the technology yet I can not use it. It is apparent that this is a problem and the AMD fails to deliver; thus, it does seem that we indeed have the Delivery Problem. Please urge your superiors to add the UVD information to the Total open source graphics Plan.

I realize that the AMD plan is already better than the non-existant NVIDIA plan, but the Intel are making far more git commits and the AMD really should do more where they can.

energyman

10-30-2009, 06:16 AM

xiando, Bridgman explained it in the past SEVERAL TIMES why documenting UVD is hard and will probably never done.
Before you continue your whining, why don't you read the archives first?
(little hint: it is about not enabling people to circumvent DRM on Windows and some hefty fines).

Why do you think it is AMD's choice?

mirv

10-30-2009, 06:28 AM

Powerplay 'mostly'?

Does.. . does that mean I can try the free driver without being killed by the fan on my 3870?

Drivers should now come with a warning - caution: use of this driver may cause physical injury, or video card sprouting wings and trying to be an aeroplane.

energyman

10-30-2009, 06:39 AM

seriously, with the open drivers the fan on my card is on max. (and the system needs 60W more). The fan is loud. Really, really, really loud.

droidhacker

10-30-2009, 08:48 AM

What makes you think that UVD is even required for comfortable video decode?

I have a few points to make regarding this point;
1) If you remember back many years, you could get an "MPEG CARD" to playback MPEG videos (1 or 2? Both? I don't quite remember). This was necessary at a time when CPUs weren't powerful enough to drive SD videos, so they accelerated SD video decoding. Anyway, point is that NOBODY is interested in acceleration when dealing with SD MPEG 1/2 now since the CPU usage in decoding those is negligible -- we only accelerate the down/up scaling and similar transformation using Xv.
2) Modern CPUs are basically *borderline* in handling modern HD videos on a single core. Older CPUs are borderline when using MULTIPLE cores. That means that the total acceleration doesn't really need to be *that much* in order to get a reliable playback.
3) WELL DOCUMENTED GPU features can be used for partial video-decode acceleration. As bridgman has pointed out in other threads, this partial video decode acceleration is actually *MOST* of the video decode process. To me that suggests that rather than sucking up most of my older multi-core CPU running at full speed, video decoding might drop down to, for example, half of a single core at half speed, which is low enough that I don't worry about it, even on a laptop since the CPU will be in a power-saving low-frequency mode.

Could it be better? Sure, we could make full use of UVD, BUT, it is not *so critically important* that we can't live without it.

My opinion: GPU hardware video decode acceleration is a product of bad-DRM. Without bad-DRM, video decode acceleration would most likely be done using standard GPU features for equivalent video playback performance at slightly higher CPU usage. I.e., the proposed video-decode-over-gallium. Putting video decode into a dedicated chip makes it harder to reverse engineer since DRM-infested bad goes in to hardware, and clear video (w/HDCP) comes out the HDMI port on the other side of it. I.e., it enables the "magic black box" feature.

This indicates that the secret AMD total plan for AMD World Order is flawed.

That the AMD apparently does NOT want me or my family to have access to the UVD programming information is a serious problem, I have the technology yet I can not use it. It is apparent that this is a problem and the AMD fails to deliver; thus, it does seem that we indeed have the Delivery Problem. Please urge your superiors to add the UVD information to the Total open source graphics Plan.

I realize that the AMD plan is already better than the non-existant NVIDIA plan, but the Intel are making far more git commits and the AMD really should do more where they can.

Kano

10-30-2009, 09:08 AM

arbitrabbit

10-30-2009, 06:43 PM

Video accelleration for h264/vc1 is certainly nice to have. As ATI does not provide a similar feature as Nvidia with VDPAU those cards are only 2nd choice for systems which should decode full hd. The curious thing about that is XvBA was here even before VDPAU was introduced, but only same privileged people could use it (some famous OEMs...). That's the wrong way as video accelleration has got lots of issues usually when it is introduced and without testers the quality will never be good. vdpau with bad content used crashed the Xserver too in the beginning. The drivers needed to improve over time. Even when you get accelleration via XvBA tomorrow there still would be lots of errors which are no more in VDPAU. ATI really missed the best time to introduce it - now the best they could do is implementing vdpau and forget their own lib.

Absolutely agree. I am one of the part time Linux users that was discussed in one of the previous threads on the same topic who probably don't count towards the Linux stats that ATI counts, however I can say one thing quite honestly. Had I read these threads (and I do intend to publicize this as this information is not available very easily - at least people on forums like slashdot seem to think that ATI is a better bet on Linux due to companies support for Linux), I would have bought an Nvidia card instead of an ATI one. What AMD/ATI probably doesn't realise is that lack of UVD support on Linux actually affects their share of Windows market share as well. I think as an end user, I can only vote with my wallet.

To be fair, an average end user doesn't care about the ideology behind open source vs. closed source as long as we can get a working driver that delivers the advertised features. So can we please get something that works and have a open source vs. closed source DRM debate on the side?

pingufunkybeat

10-30-2009, 09:13 PM

Personally, Open Source drivers are FAR more important than UVD.

AMD is doing a good thing (tm) by supporting free drivers. UVD would be nice, but there's no way in hell that I'd be buying nVidia for some cooler video playback at this time

To be fair, an average end user doesn't care about the ideology behind open source vs. closed source
The average Windows user doesn't.

Ant P.

10-30-2009, 09:53 PM

seriously, with the open drivers the fan on my card is on max. (and the system needs 60W more). The fan is loud. Really, really, really loud.

The git driver has had power management for a few months now. I'm using this on mine and the case temperature stays below 35°C:
Section "Device"
Identifier "HD4350"
Driver "radeon"
Option "ClockGating"
Option "DynamicPM"
Option "ForceLowPowerMode"
EndSection
...just don't let X crash or your card's going to fry again. Happened to me once already...

arbitrabbit

10-30-2009, 10:26 PM

Personally, Open Source drivers are FAR more important than UVD.

AMD is doing a good thing (tm) by supporting free drivers. UVD would be nice, but there's no way in hell that I'd be buying nVidia for some cooler video playback at this time

The average Windows user doesn't.

Define an average Windows user? I have been using Linux for the past 9 years and I still don't care about the ideology. For me, it is all about the best tool for the job, where the job in my definition is a secure OS where I can do the most basic tasks like web browsing, word processing, spreadsheeting and yes, watching videos and listening to music easily. The reason I use Linux is because I personally feel that it has lower cost of ownership than windows and is a lot more customisable.

On the other hand my parents also use Linux but they simply use it because I installed it (as it was easier for me to maintain remotely) and they don't even know what Linux or Windows is. For them everything is the "computer" and they take everything else for granted.

And with distributions like Ubuntu, you bet that the number of users who care more about usability rather than ideology are only going to increase. So don't make assumptions about the average Linux user nowadays.

beecher

10-31-2009, 05:48 AM

The git driver has had power management for a few months now. I'm using this on mine and the case temperature stays below 35°C:
Section "Device"
Identifier "HD4350"
Driver "radeon"
Option "ClockGating"
Option "DynamicPM"
Option "ForceLowPowerMode"
EndSection
...just don't let X crash or your card's going to fry again. Happened to me once already...

Does this work with the driver from Ubuntu 9.10 ?
Thanks.

pingufunkybeat

10-31-2009, 09:23 AM

Define an average Windows user? I have been using Linux for the past 9 years and I still don't care about the ideology.
This is hardly average.

And just because you don't care about the ideology doesn't mean that others don't. Shoving closed drivers down everyone's throats so your CPU runs a bit cooler is not what everyone wants.

So don't make assumptions about the average Linux user nowadays.
I didn't, you did.

myxal

10-31-2009, 10:13 AM

This is hardly average.
Please provide some sources/data which would suggest your claim is true. To me, and apparently others, "average Linux user cares more about opensource than his hardware working" just doesn't pass the laugh test. It might have been true in the days of yore when no one bothered to offer pre-compiled packages because everyone using linux was either a coder or had no issue compiling programs on their own. Those days are, thankfully, long gone.

And just because you don't care about the ideology doesn't mean that others don't.I know the plural of anecdote isn't 'data', but count me in the "cares about using hardware features first, about opensource second" crowd. The number of nvidia users (see Phoronix Graphics survey) is also telling. Or are you saying all those nvidia users are windows users who just switched to Linux and haven't changed their hardware? :D Shoving closed drivers down everyone's throats so your CPU runs a bit cooler is not what everyone wants.Shoving? You got the docs, you got the free drivers (crippled as they are) what do you care what happens in the closed source driver? Are you using it at a gunpoint?

amphigory

10-31-2009, 11:14 AM

Does this work with the driver from Ubuntu 9.10 ?
Thanks.
Not with KMS in my experience. Check your /var/log/Xorg.0.log. Mine shows:
(WW) RADEON(0): Option "DynamicPM" is not used
(WW) RADEON(0): Option "ForceLowPowerMode" is not used

I'm running 2.6.32-rc5 and drm/mesa/xf86-video-ati git master.

pingufunkybeat

10-31-2009, 01:21 PM

Shoving? You got the docs, you got the free drivers (crippled as they are) what do you care what happens in the closed source driver? Are you using it at a gunpoint?

I was clearly referring to this:

To be fair, an average end user doesn't care about the ideology behind open source vs. closed source as long as we can get a working driver that delivers the advertised features. So can we please get something that works and have a open source vs. closed source DRM debate on the side?
So I didn't start the debate on what the average linux user wants, I just said that I don't want the excellent work that AMD is putting into open-source drivers shouldn't be sabotaged so we can get add DRM to the binary blob faster.

I care about open infrastructure, and there are many others who do, too. I don't want somebody else deciding that linux should be half-open and half-closed in the name of the mythical "average user".

The number of nvidia users (see Phoronix Graphics survey) is also telling.
Yes.

It is telling that AMD hardware only got the ability to play videos properly on Linux a couple of months ago and that nVidia was the only option in the past.

It is not telling that people don't want open-source drivers.

mirv

10-31-2009, 03:16 PM

arbitrabbit

10-31-2009, 03:57 PM

AMD are not sabotaging open source driver work in favour of binary blobs. AMD are putting more work than was originally intended into the open source drivers.
It was the community who said "just give us the documentation, we'll do the rest". AMD has done that, and has given extra support to help in the development of the drivers. If anything, AMD has lessened work on fglrx to help with open source stuff (though, I would point out that in doing so AMD does not have to support older video cards in fglrx).

However, they haven't given the documentation to exploit UVD in open source drivers and reading Bridgman's comments in many threads, it is reasonable to assume that they probably never would (after a detailed study where the senior management is more than likely to veto the idea of releasing the specs if that would increase the likelihood of AMD's DRM to be broken, but only benefits a miniscule proportion of their user base).

That is where my rant started really, that can we have the open source vs. closed source debate on the side and give top priority of getting something working out first, be it closed source or open source. As I said, according to me an average user probably doesn't care about where the driver is coming from, be it AMD or the community, as long as it works. And if your post is correct that AMD is prioritising open source over closed source, it does give me some reason to be concerned as for reasons I mentioned above, AMD are highly unlikely to release the specs for the UVD Asic to the community, but the increased focus on open source driver would probaly delay the availability of those features in their closed source driver as well. I certinaly hope it doesn't happen but can we continue having this open source vs closed source debate with AMD but without letting the users hang in the mean time?

bridgman

10-31-2009, 04:36 PM

That is where my rant started really, that can we have the open source vs. closed source debate on the side and give top priority of getting something working out first, be it closed source or open source.

That's what is happening today. Other than having everything happen instantly what would you like to see changed ? I have said (about 20 times) that UVD support is likely to come out in the closed driver before the open driver, and that is still our thinking.

In the meantime, the open source work is starting to shift focus to Gallium3D, which is a practical pre-requisite for decode acceleration *without* relying on UVD.

I think all the things you want are happening.

I certinaly hope it doesn't happen but can we continue having this open source vs closed source debate with AMD but without letting the users hang in the mean time?

At the risk of offending everyone here, I guess I should make it clear that we are *not* waiting to see what decisions come out of the discussion on Phoronix before doing any work on open or closed drivers :D

monraaf

10-31-2009, 04:50 PM

As I said, according to me an average user probably doesn't care about where the driver is coming from, be it AMD or the community, as long as it works.

You are probably right that a lot of users don't care, until AMD decides to drop support for their hardware in their proprietary driver (as has happened early this year with R300-R500 cards), then they are suddenly outraged.

I can't wait when AMD decides to nuke support for R600 cards in their proprietary driver next year, then we'll have the same ritual again. All those people who didn't care about open source in the first place suddenly start whining again, like something totally unexpected just happened.

For me I find all this quite amusing, this is what you get when relying on closed source software.

myxal

10-31-2009, 05:59 PM

For me I find all this quite amusing, this is what you get when relying on closed source software.Yeah, because opensource drivers never drop support for older hardware... oh wait, that's bullcrap. 3D on i815 is (was) broken last time I checked and Intel ain't touching it to fix it.

energyman

10-31-2009, 06:09 PM

Yeah, because opensource drivers never drop support for older hardware... oh wait, that's bullcrap. 3D on i815 is (was) broken last time I checked and Intel ain't touching it to fix it.

since it is opensource you are free to fix it yourself.

myxal

10-31-2009, 06:21 PM

So what? If the fix was easy Intel would already integrate it. Trouble is the driver is apparently bad from an architecture standpoint (the -i810, not -intel) so fixing it involves pretty much rewriting the whole i810 driver for newer x.org architecture (or further hack to intel driver to support i8xx hardware). My chances of succeeding at that are about the same as getting unsupported hardware to work with newer fglrx or using old fglrx with new x.org. I'm left to only buying a newer card (whole system, actually) in both cases.

The most important thing is docs and AMD already provides those for most of the stuff their cards can do. If you want docs for UVD, get the stupid legislation that allows Macrovision and MAFIAA to pound AMD for providing docs revoked. But that involves politics, and the free software community was never good with that.. :-\

Edit: I guess what I was getting at was something like this:since it is opensource you are free to fix it yourself.Wrong. I can (theoretically) fix it because there are docs. Opensource is meaningless without good docs, vendor support, or both. For reference, see nv graphics driver, or Ralink wireless driver.

amphigory

10-31-2009, 07:00 PM

At the risk of offending everyone here, I guess I should make it clear that we are *not* waiting to see what decisions come out of the discussion on Phoronix before doing any work on open or closed drivers :D

Oh oh... I am so offended! Please offend me more if it a dependency for Gallium3D work or kernel power management. :-)

I think you guys are doing a bang-up job with the AMD video driver stack. Having waded through 11 years of crap Linux video drivers, the R500 support I am now enjoying is a breath of fresh air.

I almost wish I would not have started this thread. I only was curious which API would be supported in the future. Again, thanks for the great work you guys are doing.