Announcement

Collapse
No announcement yet.

Blumenkrantz Flushes 17.1k Lines Of Old Mesa Code

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

  • mangeek
    replied
    Originally posted by stormcrow View Post

    The only way V4L2 is going to be "replaced" is for something that takes its place...
    Don't a lot of the specialized ASICs on some GPUs use V4L2 as an interface? Like the IPU on some Intel processors? I wasn't sure if V4L2 was specifically and strictly limited to video-for-linux or if the actual uses of the kernel subsystem have been taken advantage of for purposes that perhaps it wasn't originally intended for.

    Leave a comment:


  • agd5f
    replied
    Originally posted by Quackdoc View Post

    thanks for letting me know, guess ill look into using openmax, not sure what any of the pros and cons are of it though, but could be neat to look into.
    OpenMAX was originally supported because it was the only video encode and decode API at the time supported on Linux and it was a Khronos standard. That said, most apps use VA-API today so there is no real need to use OpenMAX unless you have an existing use case for it.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by agd5f View Post

    gstreamer has support for it. We have a number of customers that use gstreamer over OpenMAX.
    thanks for letting me know, guess ill look into using openmax, not sure what any of the pros and cons are of it though, but could be neat to look into.

    Leave a comment:


  • agd5f
    replied
    Originally posted by Quackdoc View Post

    Just curious, Openmax support is cool and all, but I am a little confused on if it's actually used? do you know if there is anyone actually using mesa's openmax in production for anything? or is it something just kinda nice to have? Off the top of my head, maybe android? I realize gstreamer as openmax support too, but im wondering if anything utilizes it that would be paired with mesa.

    been something eating at the back of my mind on and off for a while
    gstreamer has support for it. We have a number of customers that use gstreamer over OpenMAX.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by agd5f View Post

    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.
    Just curious, Openmax support is cool and all, but I am a little confused on if it's actually used? do you know if there is anyone actually using mesa's openmax in production for anything? or is it something just kinda nice to have? Off the top of my head, maybe android? I realize gstreamer as openmax support too, but im wondering if anything utilizes it that would be paired with mesa.

    been something eating at the back of my mind on and off for a while

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • Vistaus
    replied
    Originally posted by carewolf View Post
    Awesome. Give some props and visibility for code cleanups
    Agreed, but the anti-code removal movement will disagree.

    Leave a comment:


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

    Leave a comment:

Working...
X