Remove Xvmc (x11 video motion compensation) extension

[metux]

Describe the idea

• drop the Xvmc extension
• phase 1 (abi 25): drop protocol supports, but leave ABI stubs in place)
• phase 2 (abi 26): also drop the ABI stubs

It should be done because

• deprecated and practically non-functional for many years now, totally unmaintained
• pretty tied to ancient MPEG2 (and only main profile!), not useful for modern codecs
• practically no active clients anymore (one needs really old versions for it)
• needs client-side drivers, practically non-existing anymore
• server side drivers: only few drivers, just for ancient HW. Often broken or insecure (eg intel i800)
• summary: pretty much useless and potentially harmful

What are the alternatives?

Invest A LOT of manpower to make it practically work again.

Additional context

No response

Extra fields

• I have checked the existing New Ideas, RFCs Of The Core Team, Ideas Soon To Be Addressed and Someday Ideas
• I have read the Contributing Guidelines
• I'd like to work on this idea

[metux]

@X11Libre/wranglers

[metux]

See PR X11Libre/xserver#808 for a RFC queue.

[stefan11111]

@metux What about things like DirectFB (the original, not DirectFB2) and old games.]
Some games need a libc from gcc3, for example.

X11's main advantage is backwards compatibility and a lot of existing X11 client code.
I don't think we should remove stuff without a big reason, like the code no longer building, for example.

[metux]

@metux What about things like DirectFB (the original, not DirectFB2) and old games.] Some games need a libc from gcc3, for example.

How is that related to Xvmc ?

X11's main advantage is backwards compatibility and a lot of existing X11 client code. I don't think we should remove stuff without a big reason, like the code no longer building, for example.

Are there any existing (actively used) clients still supporting Xvmc (that can't use something not that ancient, eg. VA-API/VDPAU/GL) ?
Are there still users (on Xlibre, not frozen some old Xorg/Xfree86 release) having one of the few cards where the driver actually supported Xvmc ?

Note that last actual work on this (except for minor maintenance) is now decades ago.

[BourgeoisBear]

looks like fifty shades of unsupported on the drivers front

https://en.wikipedia.org/wiki/X-Video_Motion_Compensation#Hardware_manufacturers

[BourgeoisBear]

Sounds like a great candidate for removal, but it would probably be better to have a testbed to verify if any future changes will cause breakages downstream. That way we can cut straight to the data instead of having long-ass github debates. If Qt, GTK, GLFW, WxWidgets, Gnome, & Xfce build, 99% of clients are probably A-OK. If we discover any shortcomings in our test suite, we can always add new tests.

Actually, ffmpeg would probably be the most important test for this. They have extensions for everything under the sun.

https://ffmpeg.org/doxygen/1.0/group__lavc__codec__hwaccel__xvmc.html

From a hardware perspective, it probably makes no sense with recent machines anyway. Faster to do it with the CPU than shuffle it across the PCIe bus, especially when the CPUs are becoming more GPU-like with each passing release.

[metux]

Sounds like a great candidate for removal, but it would probably be better to have a testbed to verify if any future changes will cause breakages downstream.

Sure. We should get the CI tests actually up and running. Do you like to take care of this ?

Actually, ffmpeg would probably be the most important test for this. They have extensions for everything under the sun.

https://ffmpeg.org/doxygen/1.0/group__lavc__codec__hwaccel__xvmc.html

v1.0 - that is over a decade ago.

my machine (devuan) has 5.1.7 - no xvmc support anymore. the source still has some little garbage pieces left of it, that's not used at all (one unused header libavcodec/xvmc.h, that's not included anyhwere).

From a hardware perspective, it probably makes no sense with recent machines anyway. Faster to do it with the CPU than shuffle it across the PCIe bus, especially when the CPUs are becoming more GPU-like with each passing release.

Indeed. And not at all supported by non-acient hardware.
And who's really still heavily using MPEG2 ?

[BourgeoisBear]

I'm more of an EE guy. If I knew anything about CI, I'd have already done it. I can take a stab at it if we don't already have a more capable contributor on that front. The best I know how to do at the moment is run make and see if it barfs.

[shamefulCake1]

And who's really still heavily using MPEG2 ?

Well, people have huge collections of DVDs, and old portable cameras created a lot of home videos.

But as far as I remember, nvdec can accelerate mpeg2 all right.

[shamefulCake1]

I don't understand most of the terms used in this RFC, but I vaguely remember XvMC being touted as "the new better way of video output acceleration" about 15 years ago.

It's a bit sad to see it go in such an inglorious way.

On the other hand, I have never seen anything supporting it on my hardware, even though there were some switches to mplayer or xine about 20 years ago.

[metux]

I don't understand most of the terms used in this RFC, but I vaguely remember XvMC being touted as "the new better way of video output acceleration" about 15 years ago.

Actually, 20 years ago. We're talking about GPUs from late 90s / early 2k.
I'm not even sure whether I ever had it practically running back then (P2, P3 machines), because only few GPUs ever supported it.

It's a bit sad to see it go in such an inglorious way.

Well, the general idea was quite nice back then. But it only has several major drawbacks, eg. tied to MPEG2. Back then the most practical use cases were watching SCVD (maybe early DVD), which already been legacy back then. (most of my videos already had been MP4). And it's only doing the MC part. So scope always had been very limited.

It would have been different if they had designed it to offload complete decoding pipeline (everything between demux and final composition) to the Xserver, and allow it to support various codecs. But unfortunately they didn't do it.

I'm actually thinking about creating a new extension that does full decoding (with pluggable codecs), but that's an entirely different story.

On the other hand, I have never seen anything supporting it on my hardware, even though there were some switches to mplayer or xine about 20 years ago.

Exactly. That's why I believe, we don't need to carry this around anymore.

[algrid]

Can we make it disabled by default, but leave the possibility to enable it (during the build or runtime) and then wait for feedback? Maybe add some message that this feature is gong to be deleted. And then wait for some time and see if anyone reports it as really needed.
Would such approach make sense technically?

[metux]

The point is: right now it's quite broken, we have no practical way to test it (no supported HW), and needs lots of refactoring for upcoming things (so yes, it's a blocker for future things right now).

If it had actually practical users, and volunteers to actually maintain it, then we certainly would keep it. But right now it's just pretty much dead code.

Note that it's only suited for MPEG2 alone (no other codecs), and only supported by few drivers for very, very old hardware.
And I didn't easily find any non-ancient client for this. Not aware of any existing current client at all.

Why should we keep anything that's not used at all ?

[stefan11111]

The point is: right now it's quite broken, we have no practical way to test it (no supported HW), and needs lots of refactoring for upcoming things (so yes, it's a blocker for future things right now).

What about intel hw? I know the driver has an option to support xvmc.

[metux]

The point is: right now it's quite broken, we have no practical way to test it (no supported HW), and needs lots of refactoring for upcoming things (so yes, it's a blocker for future things right now).

What about intel hw? I know the driver has an option to support xvmc.

It does have some limited support for really old GPUs, from i810 to i915. And only for MPEG2 in basic profile (eg. older DVDs).
OTOH, my old P3 machine could already smoothly play back fullscreen MP4 without any GPU support (it ran on dumb VESA FB, because of NVidia) - that's now 25 years ago.

By the way, if your HW does have some HW codecs (actual codecs, eg. H264), you can also use them today - w/o Xvmc - via V4L & dmabuf. An X11 extension for doing it in a generic way (w/o special client-side drivers), even remote (which Xvmc never supported) would be a cool thing. But that's far out of scope of Xvmc.

[algrid]

I'm ok with removing it, if no one is using it. Just trying to be extra cautious. Sometimes some ancient tech comes back from some really unexpected places...

[callmetango]

The big question for me is: What is XvMC for? If I understand https://en.wikipedia.org/wiki/X-Video_Motion_Compensation right then it is used for accelerating MPEG-2 video decoding which is used in DVDs, correct?

[metux]

The big question for me is: What is XvMC for? If I understand https://en.wikipedia.org/wiki/X-Video_Motion_Compensation right then it is used for accelerating MPEG-2 video decoding which is used in DVDs, correct?

Correct. It's based on Xv (XVIDEO extension) and allows offloading the the motion compensation and iDCT part of MPEG2 decoding (base profile, only) to the GPU - if it supports it. Two decades ago, some GPUs had special logic for this, but it was quickly replaced by generic shaders (GL). NVidia's proprietary driver never supported it, btw.

Except for some acient Savaga, VIA or i810, I don't recall any GPU that's supporting it, but can't do the same via shaders.
(and even on them, one could do it via V4L).

Can't imagine any production system, that's going to be running next XLibre release, on those specific HW configuration, that really needs to play MPEG2 and can't do it w/o XvMC.

[callmetango]

Thank you. Regarding the generic shaders (GL): Are they available in the older cards too? AFAIK back in the days some algorithms were cast in hardware because they would otherwise have been too slow. Are the shaders equivalent in terms of speed? And are they also available in equivalent form in these older graphics cards? Or do they only support what XvMC is for?

one could do it via V4L

What do you mean by that? And doesn't V4L mean Video for Linux and if so what about the BSDs and other operating systems?

[metux]

Thank you. Regarding the generic shaders (GL): Are they available in the older cards too? AFAIK back in the days some algorithms were cast in hardware because they would otherwise have been too slow.

We're talking about really old cards here. And also note that we only ever supported very few cards ever.

• intel i810 and never --> have unified shaders (anything above i810 already does use shaders under the hood, for i810 I'm not 100% sure)
• VIA/S3 unichrome --> have unified shaders
• nvidia --> old cards used to have dedicated decoder logic, but nouveau implementation seesm really incomplete (supports surface creating, but can't find actual decoding instructions), and IIRC those were one of the first supporting unified shaders
• old ATI --> same here, also IMHO supporting unified shaderes

I wonder whether any of the currently supported ones wouldn't work with shaders, actually doubt it.

Are the shaders equivalent in terms of speed?

For the cards having supporting unified shaders, it's highly likely that those operations are implemented as shader operations under the hood (either by driver or in microcode/firmware), so I wouldn't expect any notable performance difference.
Of course, I don't have those cards, so can't actually measure it.

And doesn't V4L mean Video for Linux and if so what about the BSDs and other operating systems?

FreeBSD at least does support it. Not sure about the others, but those rarely are used on desktops (let alone MPEG2 playback) on such old machines.

And let's not forget that this is only MPEG2 in basic profile, nothing else.

[AndersonTorres]

Let me see if I understood this:

• Xvmc enables to offload some very specific computation to a video card that has a very specific hardware
• The cards with that hardware are old and rare
• The cards with that hardware have other means to process this computation

Is this it?

[YusufKhan-gamedev]

Why is XV being disabled in the PR? Its still used by consumers such as ffmpeg.

[rowheel]

Invest A LOT of manpower to make it practically work again.

LMFAO 🤣🤣