XvMC Support Now Disabled By Default In Mesa

[phoronix]

Phoronix: XvMC Support Now Disabled By Default In Mesa

For those that haven't jumped onto the VDPAU state tracker bandwagon with the Gallium3D graphics drivers but are reliant upon the XvMC state tracker, your days may be limited. While the XvMC support code is still found within Mesa, it's now disabled by default...

http://www.phoronix.com/vr.php?view=MTU3MDM

[mrugiero]

I won't argue the decision, as it's true that it's not used that much nowadays (at least not in currently supported drivers, anyway), but the motivation seems counter intuitive, I mean, unit tests fail, so instead of fixing whatever makes them fail, they disabled the build on the default configuration. The only way that reasoning makes sense to me is if the idea is to point out "well, this is in no conditions for production use, use it at your own risk", but nothing else.

[Ericg]

I won't argue the decision, as it's true that it's not used that much nowadays (at least not in currently supported drivers, anyway), but the motivation seems counter intuitive, I mean, unit tests fail, so instead of fixing whatever makes them fail, they disabled the build on the default configuration. The only way that reasoning makes sense to me is if the idea is to point out "well, this is in no conditions for production use, use it at your own risk", but nothing else.

Preeeeeeeeeeeeetty much. I think this was mostly a "We finally have excuse to kill this" move. Checking out Arch's wiki page for XVMC I see the following faults in XVMC:

1) Support -- Only Mplayer and Xine have any sort of support for XVMC. (Just checked VLC, it only supports XVideo, not sure if thats newer or older than XVMC though)

2) Targets -- You're only guaranteed acceleration for MPEG-1 and MPEG-2, anything else will probably fail and get shoved to the CPU anyway

3) Obsolete-ness -- Anything that you really want to bother doing acceleration on is probably support by VA-API, VDPAU, or at worst XvBA.

And thats only looking at a very high level view of the project as a whole. Who knows the last time it was properly tested in a RUNNING environment, when it was last maintained, if it HAS a maintainer, or when the last bug fix was for anything beyond "It doesnt compile against XYZ release of ABC project."

[mrugiero]

it only supports XVideo, not sure if thats newer or older than XVMC though

IIRC, XVideo accelerates even less of the process, doing only the scaling, and it's older. Maybe I remember it wrong, although checking it is fairly trivial, the specs for those extensions are in FDO, IIRC.

[mark45]

Any patch that kills any of those old shitty alternatives to VA-API and VDPAU are A GOOD THING (TM) (C).

[imirkin]

Who knows the last time it was properly tested in a RUNNING environment, when it was last maintained, if it HAS a maintainer, or when the last bug fix was for anything beyond "It doesnt compile against XYZ release of ABC project."

Works great with nouveau on NV40-NV96 cards (PMPEG and VP2 engines), better than VDPAU does for MPEG1/2's. Neither of these decoding engines don't have support for bitstream-level MPEG1/2 acceleration, which means that the mesa VDPAU impl has to do the decode in software (and it can't use libmpeg2 due to license incompatibility, so it's reimplemented). And not that much attention is given to it, compared to, say, mplayer. At present, it's buggy and slow.

In a perfect world, there would be a VA-API state tracker which enables exposing acceleration levels (so you could say IDCT-only vs full-stream), but until that happens, XvMC is superior for supporting that sort of older hardware. [Apparently there was a vaapi state tracker at one point, but it was removed, presumably due to disrepair.]

[Vim_User]

Can somebody explain to me if this is relevant for owners of hardware that just can't use the "well supported VDPAU", for example with RS780/880 or RV790? And if it is relevant, what are the implications of this?

[TemplarGR]

Can somebody explain to me if this is relevant for owners of hardware that just can't use the "well supported VDPAU", for example with RS780/880 or RV790? And if it is relevant, what are the implications of this?

Modern cpus(decade old) don't need hardware accel. for mpeg1/2... They are quite powerful...

[GreatEmerald]

I always use either VDPAU or OpenGL for video rendering. VDPAU for the things it supports (a fairly limited set of codecs) and OpenGL for correct rendering (no other output device I tried could play 4:4:4 chroma subsampling videos correctly, they all would recode it to 4:2:0 or such).

[rohcQaH]

I mean, unit tests fail, so instead of fixing whatever makes them fail, they disabled the build on the default configuration. The only way that reasoning makes sense to me is if the idea is to point out "well, this is in no conditions for production use, use it at your own risk", but nothing else.

The issue is not that unit tests fail, the issue is that nobody is maintaining it and it starts to bitrot.

Now you're saying that "they" should just keep maintaining it, but how do you enforce something like that in a community project? No volunteer cares enough about the feature to maintain it, no company cares about the feature enough to pay someone to maintain it.. and in fact, most people aren't even using it. What now?


Unless someone steps forward to maintain it, the only way to go is to disable it by default. If it deteriorates further, remove it.