3 ms·

The open source driver doesn't use VMCS, it instead puts aside a fixed block of memory (typically 256 MiB, which I think is also a limit due to some hardware bu

The open source driver doesn't use VMCS, it instead puts aside a fixed block of memory (typically 256 MiB, which I think is also a limit due to some hardware bugs) for use through the Linux Contiguous Memory Allocator (CMA) that it then draws from. VMCS only comes into the picture if you use video decode, but I think Dave Stevenson from the foundation hacked the firmware side to support importing Linux allocated memory blocks into VMCS so that you can do zero-copy decode and import into EGL (or more likely HVS, the EGL support for the formats is pretty limited). (I really liked the design of the HVS - having pretty much scripted planes is a fresh approach over similar hardware blocks that have a fixed number of planes each with own idiosyncracies and limitations)

mrlambchop 8y ago
The HVS was a cool design - the only real issue if I recall was its limited line buffers meaning it was hard to determine what could be composited in real time, so we ended up always rendering to a triple buffer. It also did some amazing scaling in realtime, but this came with some crazy artifacts that were super painful to triage. The occasional "flash of bad pixels" in a live composition screen was really painful. I just remember I wrote the DPI and CPI peripherals that we brought up the HVS with - on a 4MHz FPGA complex, we had YUV camera input scaling up to a WVGA DPI screen running at 60fps on a distributed FPGA platform through the HVS. Fun times.