3 ms·

> Not sure if there are Vulkan Video implementations for things that are not GPUs yet Qualcomm video acceleration is stateful, and as such doesn't fit with the

• jchw 2y ago
  I'm afraid I don't know enough about hardware-accelerated video encoding/decoding to really understand what this implies. From what I gather, the Vulkan API gives you the ability to queue video encode/decode operations, which seem to pertain to e.g. a frame of h264 video, passing in all of the required state. So I assume at a low level, how a driver would have to handle this is by processing these commands, dispatching units of work to relevant hardware units, flipping registers and etc. as needed, and doing whatever can't be done in hardware in software. And I guess what you mean when you say Qualcomm's video acceleration is "stateful", it means that you can't just simply dispatch a single-frame encode job, the video encoding process is some stateful thing where the per-codec state is not all exposed and cannot be processed out-of-order, so there's no logical way to implement a Vulkan driver. If so, that's a bummer. I wonder if it might be possible to "cheat" by having a driver that tries to use stateful acceleration in the happy path, but falls back to software encoding/decoding when things go out of order or there are no more hardware resources. Probably not. At least, hopefully, future hardware designs will account for this. Until those existing devices are outside of their useful lifespan, though, it seems Vulkan Video will probably not be the one hardware video coding API to rule them all.
  • my123 2y ago
    > And I guess what you mean when you say Qualcomm's video acceleration is "stateful", it means that you can't just simply dispatch a single-frame encode job Yup it's exactly that