Blumenkrantz Flushes 17.1k Lines Of Old Mesa Code

[Quackdoc]

It seems like v4l2 is about to get replaced too so doing anything to work with it doesn't seem like a good idea.

nah v4l2 isn't going anywhere. and even if this CAM api does replace it for cameras, I doubt it would cover hw encoding and decoding too

[browseria]

nah v4l2 isn't going anywhere. and even if this CAM api does replace it for cameras, I doubt it would cover hw encoding and decoding too

Are you sure? What about libcamera?

[stormcrow]

It seems like v4l2 is about to get replaced too so doing anything to work with it doesn't seem like a good idea.

The only way V4L2 is going to be "replaced" is for something that takes its place that leaves the current V4L2 API in place unchanged. This means any new reworks of V4L2 would start by refactoring existing code and extending the API rather than altering the API already there. Linus is not going to allow user space breakage of that magnitude. (He generally doesn't allow any user space breakage into his kernel tree.) Any new drivers that wouldn't be able to exist inside the V4L2 will just add another user space API. Anything needing to make use of the new API calls would have to be written to do so, but no existing programs would be broken.

[Amaranth]

The only way V4L2 is going to be "replaced" is for something that takes its place that leaves the current V4L2 API in place unchanged. This means any new reworks of V4L2 would start by refactoring existing code and extending the API rather than altering the API already there. Linus is not going to allow user space breakage of that magnitude. (He generally doesn't allow any user space breakage into his kernel tree.) Any new drivers that wouldn't be able to exist inside the V4L2 will just add another user space API. Anything needing to make use of the new API calls would have to be written to do so, but no existing programs would be broken.

It wouldn't be breakage, it would just be a new API for new devices/capabilities. Eventually all the devices that use v4l2 would go away and v4l2 would get removed, probably in like 20 years.

[Quackdoc]

Are you sure? What about libcamera?

libcamera would sit above V4l2 or the new CAM api iirc

[oiaohm]

It wouldn't be breakage, it would just be a new API for new devices/capabilities. Eventually all the devices that use v4l2 would go away and v4l2 would get removed, probably in like 20 years.

https://www.kernel.org/doc/html/late...roduction.html
v4l1 has not 100 percent gone away notice the " 6.1.4. v4l1compat.so wrapper library" So in 20 years time v4l1 and v4l2 with the Linux kernel most likely will still be there as abstraction layers to what ever exists at the time.

Linux kernel rule of do not break userspace is in effect here.

Remember userspace is by Linux kernel documentation is should use one of the abstraction libraries to interface with cameras after the introduction of v4l2. But if enough application have not obeyed that direction we will see another abstraction layer for compatibility.
https://www.kernel.org/doc/html/late...-dispatch.html
There are new features as well since the time the v4l1 compatibility layer was done.


Amaranth like it or not stormcrow is right and you are right. V4L2 will be exactly like V4L1 that the API/ABI for applications will not go away. V4L1 has been removed for the Linux kernel space and downgraded to compatibility wrapper. There is no reason to believe that V4l2 future at some point will not be exactly the same as V4L1.

Its one of those fun one I can absolutely say at some point V4L2 will be removed from linux kernel space. The trap here as Application useable API its going no where.

The following is noted on the wikipedia. "V4L had been introduced late into the 2.1.X development cycle of the Linux kernel. V4L1 support was dropped in kernel 2.6.38 " (14 March, 2011) So yes we are 10 years past the removal of V4L1 from the Linux kernel space and the compatibility layer for V4L1 applications is still maintained.

Also do notice the libv4l1 library in the libv4l-introduction where this redirects old v4l1 applications that used the libv4l1 library to using v4l2 devices.

New API for new devices happened with V4L2 over V4L1 a decade ago. Do we have any reason to believe this time will be handled different so far no. If it handled the same way some abstraction layer for V4l2 and V4l1 to what ever the new one end up being what will happen. Yes just like 10 years ago when V4L1 was removed from kernel space we can expect users will be able to keep on using V4l2 and V4l1 applications as if nothing happened or with minor work around. If this is not the case it going to be breach of the rule do not break userspace of the Linux kernel.

[Vistaus]

Awesome. Give some props and visibility for code cleanups

Agreed, but the anti-code removal movement will disagree.

[agd5f]

My pre-coffee brain saw XvMC as “XMBC” and wondered why the heck XBox Media Center was included in Mesa to begin with.

In all seriousness though, XvMC really was only applicable to a few specific GPUs that use the r600 driver, right? Maybe like the Radeon HD 2000 series?

Not really a big loss as… well… what in the modern world would be using MPEG1/2 anyway?

It’s great to have continued r600 driver support for OpenGL but to be fair I don’t see this specifically as a loss.

My iMac (2007, Radeon Pro 2600) running Ubuntu in my guest room relies on r600 Gallium drivers to act as media streaming machine for company when they are here / doubles as a TV. But everything is H264 at least so 🤷♂️

XvMC targets really old hardware. It was targeted at hardware that only had partial video decode support (i.e., just Motion Compensation). All radeons with UVD hardware support VA-API, VDPAU, and OpenMAX as the hardware supports full decode support.

[lorn10]

Eirikr1848 I think you meant XvBA (which was back then the AMD Video Acceleration API for the r600) and not XvMC.

agd5f Question, the original R600 GPU aka the Radeon HD 2900 model never had any UVD hardware and therefore it also was not supported by VA-API, right? However, the R600 had the capability (like the former high-end R500 GPUs) to decode H262 & H264 content via its shaders. Would it be technically possible to add this type of shader decoding to VA-API or is a dedicated video decoding ASIC definitely always needed by VA-API?

[agd5f]

Eirikr1848 I think you meant XvBA (which was back then the AMD Video Acceleration API for the r600) and not XvMC.

agd5f Question, the original R600 GPU aka the Radeon HD 2900 model never had any UVD hardware and therefore it also was not supported by VA-API, right? However, the R600 had the capability (like the former high-end R500 GPUs) to decode H262 & H264 content via its shaders. Would it be technically possible to add this type of shader decoding to VA-API or is a dedicated video decoding ASIC definitely always needed by VA-API?

I'm pretty sure the 2900 had UVD. The mesa video pipe code already has support for shader based decode for MPEG1/2, but it's not much of a gain over CPU decoding, at least with relatively recent CPUs, since there is fair amount of overhead in switching between the CPU and the GPU in the decode pipeline.