Intel Proposes Calibrated Timestamps As It Works Towards Vulkan Video

[phoronix]

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?page=news_item&px=Vulkan-Calibrated-TS-Proposal

[microcode]

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.

[mlau]

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

[DadSchoorse]

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

The video extensions are provisional, so they are still being developed.

[Aryma]

Linux is always missing something like directshow or directx

[coder]

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.

[mb_q]

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.

[coder]

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.

[baka0815]

Does anyone know why the proposed name is

VK_EXT_calibrated_timestamps

instead of

VK_[COLOR=#3498db]INTEL[/COLOR]_calibrated_timestamps

?

[piotrj3]

Does anyone know why the proposed name is

VK_EXT_calibrated_timestamps

instead of

VK_[COLOR=#3498db]INTEL[/COLOR]_calibrated_timestamps

?

AMD also contributed to that extension, so I bet it is not Intel exclusive.