Apple's Video Decoder Driver Reaches Upstream Review, With a Hardware Design Unlike Anything Else

Apple's Video Decoder Driver Reaches Upstream Review, With a Hardware Design Unlike Anything Else

Sofus Forstreuter posted 14 patches introducing the AVD driver, the Apple Video Decoder, for upstream Linux kernel review. It is reverse-engineered, open-source, and has been several years in the making.

What it enables

Hardware-accelerated video decode on Apple M1, M2 and M3:

  • H.264
  • H.265
  • VP9
  • AV1, on M3 and newer

This is the difference between a laptop playing 4K video at a few percent CPU and one spinning its fans through a film. On a machine with no fan to spin, it is the difference between watching video and watching a slideshow.

Support for M4, M5, M6 and Neo is expected to follow, with firmware work already underway. Asahi hosts the required AVD firmware in its own avd-fw repository.

One register for everything

The hardware design is the genuinely unusual part, and the cover letter describes it better than a summary would:

“The AVD is a bit unique both as a video decoder and an IP block on Apple Silicon SoCs. Instead of following the normal ‘a register for each parameter’, AVD is programmed through one single register. This means the order of the writes are important, but its also important to ensure we dont write faster than the hardware can process. To solve this problem the driver writes the ‘instructions’ into a list of ‘segments’. A shared function then submits those to the hardware while making sure to wait each time the hardware lacks behind.”

Almost every hardware block exposes a register per parameter: write the width here, the height there, the buffer address somewhere else, then set a start bit. Order mostly does not matter, because each value has its own address.

AVD has one register and a sequence. Every parameter goes through the same address, and the hardware infers meaning from position in the stream. Get the order wrong and you have configured something else entirely. Write too quickly and the block silently misses values.

That turns driver writing into something closer to driving a serial protocol than configuring a peripheral, and it explains why reverse engineering this took years. You cannot probe registers one at a time to learn what they do. There is only one register, and its meaning depends on everything written before it.

The co-processor that runs unsigned code

The second detail is quietly remarkable:

“The block also includes Cortex-M3 co-processor that accepts unsigned code. The CM3 is not really required, but is the only way to get decode status IRQ’s. For now, the CM3 only handles decode-tunable configuration and forwards all IRQ’s to the AP. In the future this will be extended to handle the instruction submission, this would likely result in decreased power consumption, some initial testing even suggests slightly faster decode times.”

An unsigned-code co-processor inside Apple Silicon is not what most people would predict from a company with Apple’s signing posture. It is what makes the open driver practical: the project can load its own firmware onto the CM3 rather than needing a signed blob nobody outside Apple can produce.

The future direction is the interesting bit. Moving instruction submission onto the CM3 would let the main CPU hand over a decode job and sleep, rather than pacing writes itself. Early testing suggests that is both lower power and slightly faster, which is an unusual pair.

Standards compliance

The driver implements the V4L2 M2M stateless decoder API, which is the right target. Stateless means the kernel handles bitstream parsing in userspace and the driver receives already-parsed parameters, and it is the interface modern players and GStreamer expect.

Using the standard API rather than inventing one means existing software works without Apple-specific paths.

Status

Out for review on the kernel mailing list, heading for the media subsystem tree. There is no merge target announced, and a 14-patch driver introducing a new decoder will take review time.

For anyone running Linux on Apple hardware, this is one of the last substantial gaps in daily usability. The wider Asahi effort has been steadily closing them, with USB4 and Thunderbolt enablement, audio, and power management work all landing across recent cycles.

Background reading

Explainers for the concepts behind this story.