
Engineering a zero-copy Vulkan interop pipeline for VLC's libplacebo renderer
I'm spending the summer with VideoLAN fixing a bottleneck in VLC. Right now, even when a video is decoded on the GPU, VLC copies the frames down to system memory and back up again just to draw them on the libplacebo video output through Vulkan. My project is to build a zero-copy hardware interop.
Starting Google Summer of Code 2026 with VideoLAN, teaching VLC to draw GPU-decoded frames without copying them through the CPU first. The series opener: who I am and the round-trip I'm here to delete.
Read this partWeek 1 of my GSoC with VideoLAN: a first patch that changes nothing on purpose, an assumption that fell apart once I read the source.
Read this partBefore porting NVDEC to Vulkan, I got it playing zero-copy through OpenGL first, so I have a known-good reference to compare against. Then a long time reading my mentor's branch.
Read this partAn NVDEC frame decoded on the GPU, imported into Vulkan with no CPU copy, and drawn by libplacebo. It works, the 4K file plays with correct colors. Then I turned on Vulkan's validation layer and it flagged the code as illegal, the same code NVIDIA had been drawing.
Read this partLast week's validation error said my image can't be both disjoint and dedicated at once. The obvious fix was to drop the dedicated part, so I did, and the color fell apart into green noise across the sky and the water.
Read this partI had to make CUDA's copy and libplacebo's render take turns over one image, using a single timeline counter shared across both APIs with no CPU copy.
Read this partLast week I designed the handshake that keeps CUDA and the renderer from touching the same image at once. This week I wrote it, then spent most of my time making sure it was actually correct.
Read this part