Mesa 24.3 Removes Support For The Long-Abandoned OpenMAX API

[phoronix]

Phoronix: Mesa 24.3 Removes Support For The Long-Abandoned OpenMAX API

Some long-rotting code in Mesa has been flushed out today... Mesa 24.3 is now 11.6k lines of code lighter after removing support for the OpenMAX (OMX) API that was implemented as a Gallium3D state tracker long ago and hasn't seen any activity in recent years and the upstream OpenMAX standards work halted more than one decade ago...

https://www.phoronix.com/news/Mesa-24.3-Removes-OpenMAX

[Quackdoc]

o7 you were never a particularly good api, but you were an api when we needed it, so long.

[stiiixy]

I wonder just how slim a kernel and desktop environment we could make these days if we simply settled on, for the sake of hypothetical discussion, v4 era and up.

Is Redox doing this on top of the whole Rust rebuild?

[mahurinj]

I wonder just how slim a kernel and desktop environment we could make these days if we simply settled on, for the sake of hypothetical discussion, v4 era and up.

Is Redox doing this on top of the whole Rust rebuild?

I could easily be misunderstanding something, but I believe one of the pros of Redox being a microkernel is that the drivers aren't baked in, they are all user space programs so if you don't want some useless driver just don't install it.

[OneTimeShot]

I guess we have Vulcan video now (and also there are a lot fewer codecs around these days), but it's a shame that Khronos didn't have a more comprehensive set of APIs for GPUs that took off.

E.g. OpenGL was popular, but the video and audio APIs weren't. OpenCL was a bit of a mess too.... There's also room for a DirectInput API for controller abstraction.

Still, there is a general convergence these days...

[varikonniemi]

was there anything touching the core project, or was it a completely self contained module? 11k LOC sounds good, but i suspect it has absolutely no impact for end user, or even the developers.

[blackshard]

OpenMAX specs were quite a big of a mess with an exceeding level of customization and elasticity that turned around and revolved into components following the standard to often require custom workarounds to actually work, dissipating the benefits of the constraints given by a standard API. Notably, it was in use for Broadcom Videocore VPU in Raspberry PIs, but it was abandoned - thanks god! - in favor of v4l2 nowadays.

The whole specs for OpenMAX for all the three "levels" it comprises exceeds one thousands pages, just to give the idea of the complexity and excessive "broadness" of the specs, which tried to describe very different objects ranging from audio encoders to still image grabbers and decoders in a single API.

[ahrs]

One more useless dep to remove, for some reason Arch has had this enabled unconditionally for ages now. I haven't known a single consumer of it.

VAAPI is the way to go, perhaps Vulkan Video in the long term.

[marlock]

https://xkcd.com/927

image.png