Announcement

Collapse
No announcement yet.

Mesa 24.3 Removes Support For The Long-Abandoned OpenMAX API

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • marlock
    replied


    image.png

    Leave a comment:


  • ahrs
    replied
    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.

    Leave a comment:


  • blackshard
    replied
    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.

    Leave a comment:


  • varikonniemi
    replied
    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.

    Leave a comment:


  • OneTimeShot
    replied
    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...

    Leave a comment:


  • mahurinj
    replied
    Originally posted by stiiixy View Post
    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.

    Leave a comment:


  • stiiixy
    replied
    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?

    Leave a comment:


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

    Leave a comment:


  • phoronix
    started a topic Mesa 24.3 Removes Support For The Long-Abandoned OpenMAX API

    Mesa 24.3 Removes Support For The Long-Abandoned OpenMAX API

    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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
Working...
X