This week in vc4 (2017-04-10): dmabuf fencing, meson
The big project for the last two weeks has been developing dmabuf fencing support for vc4. Without dmabuf fences, when passing buffers between devices the user needs to manually wait for the job to finish on one (say, camera snapshot) before letting the other device get started (accumulating GL commands to texture from the camera snapshot). That means leaving both devices idle for a moment while the CPU accumulates the command stream for the consumer, but the bigger pain is that it requires that the end user manage the synchronization.
With dma-buf fencing in the kernel, a "reservation object" generated by the dma-buf exporter tracks the fences of the various devices using the shared object, and then the device trivers get to look at that list and wait on on each others' fences when using it.
So far, I've got my reservations and fences being exported from vc4, so that pl111 display can wait for vc4 to be done before actually putting a new pageflip up on the screen. I haven't quite hooked up the other direction, for camera capture into vc4 display or GL texturing (I don't have a testcase for this, as the current camera driver doesn't expose dmabufs), but it shouldn't be hard.
On the meson front, rendercheck is now converted to meson upstream. I've made more progress on the X Server: Xorg is now building, and even successfully executes Xorg -pogo with the previous modesetting driver in place. The new modesetting driver is failing mysteriously. With a build hack I got from the meson folks and some work from ajax, the sdksyms script I complained about in my last post isn't used at all on the meson build. And, best of all, the meson devs have written the code needed for us to not even need the build hack I'm using.
It's so nice to be using a build system that's an actual living software project.
With dma-buf fencing in the kernel, a "reservation object" generated by the dma-buf exporter tracks the fences of the various devices using the shared object, and then the device trivers get to look at that list and wait on on each others' fences when using it.
So far, I've got my reservations and fences being exported from vc4, so that pl111 display can wait for vc4 to be done before actually putting a new pageflip up on the screen. I haven't quite hooked up the other direction, for camera capture into vc4 display or GL texturing (I don't have a testcase for this, as the current camera driver doesn't expose dmabufs), but it shouldn't be hard.
On the meson front, rendercheck is now converted to meson upstream. I've made more progress on the X Server: Xorg is now building, and even successfully executes Xorg -pogo with the previous modesetting driver in place. The new modesetting driver is failing mysteriously. With a build hack I got from the meson folks and some work from ajax, the sdksyms script I complained about in my last post isn't used at all on the meson build. And, best of all, the meson devs have written the code needed for us to not even need the build hack I'm using.
It's so nice to be using a build system that's an actual living software project.