Announcement

Collapse
No announcement yet.

Intel Proposes Calibrated Timestamps As It Works Towards Vulkan Video

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

  • Intel Proposes Calibrated Timestamps As It Works Towards Vulkan Video

    Phoronix: Intel Proposes Calibrated Timestamps As It Works Towards Vulkan Video

    Since the publishing of the provisional Vulkan Video specification last month, the only driver on Linux to have exposed any early Vulkan Video support is NVIDIA's Vulkan beta Linux driver. But it would appear that Intel's open-source developers are working at least towards eventually handling this video acceleration API...

    https://www.phoronix.com/scan.php?pa...ed-TS-Proposal

  • #2
    Cool, Vulkán Video is positioned correctly for once, vs. MAX and all of the other largely incompatible and inconsistent APIs, and their various inconsistent tie-ins with graphics APIs.

    Comment


    • #3
      Curious why this didn't come up when vulkan video extensions were developed?

      Comment


      • #4
        Originally posted by mlau View Post
        Curious why this didn't come up when vulkan video extensions were developed?
        The video extensions are provisional, so they are still being developed.

        Comment


        • #5
          Linux is always missing something like directshow or directx

          Comment


          • #6
            Originally posted by Aryma View Post
            Linux is always missing something like directshow or directx
            Huh? Linux has no shortage of DirectShow-like facilities. In userspace, there's GStreamer, PipeWire, OpenMax, FFMpeg, etc. At a lower level, pluggable modules are supported in: V4L2, ALSA, JACK, etc. Even in the kernel, there's a whole framework for plug-ins called eBPF.

            What's even more askew about your comment is that this doesn't establish anything of the kind. This just allows Vulkan implementations to expose the video acceleration capabilities of devices they support. In that respect, it's not so different than other Linux video acceleration APIs, like: V4L2, VA API, VDPAU, etc. The only likely benefit will be easier integration of video acceleration into programs already using Vulkan and (hopefully) more support and better vendor conformance.

            It could reach a point where it has better support and conformance than VA API, although that's not a pure win since VA API is certainly easier to use and already well-supported by a lot of the above frameworks and userspace video programs. So, if it comes at the expense of further VA API features and support, that would be unfortunate.

            As for DirectX part, that's a family of APIs, with the main one being Direct 3D. Linux has OpenGL and now Vulkan (assuming you're not just using WINE). I've already touched on various Linux counterparts to DirectSound. However, it could well be that Linux is lacking a good counterpart to DirectInput. Off the top of my head, all I know about is SDL.

            Comment


            • #7
              Originally posted by coder View Post
              Huh?
              Aryma is right in a sense that there is no proprietary multimedia API which Linux Corporation coerces on hardware and software developers using its huge financial resources and monopolistic capabilities, this way enforcing its efficiency and correctness.

              Comment


              • #8
                Originally posted by mb_q View Post
                Aryma is right in a sense that there is no proprietary multimedia API which Linux Corporation coerces on hardware and software developers using its huge financial resources and monopolistic capabilities, this way enforcing its efficiency and correctness.
                Android is probably the closest to an open source project having that kind of influence on hardware developers. Unfortunately, Google is unwilling to force providers to provide open source drivers, even though it (currently) has the clout to do so.

                At least they're backing some open source iGPU drivers and standards like WebP and AV1.

                Comment


                • #9
                  Does anyone know why the proposed name is
                  Code:
                  VK_EXT_calibrated_timestamps
                  instead of
                  Code:
                  VK_INTEL_calibrated_timestamps
                  ?

                  Comment


                  • #10
                    Originally posted by baka0815 View Post
                    Does anyone know why the proposed name is
                    Code:
                    VK_EXT_calibrated_timestamps
                    instead of
                    Code:
                    VK_INTEL_calibrated_timestamps
                    ?
                    AMD also contributed to that extension, so I bet it is not Intel exclusive.

                    Comment

                    Working...
                    X