> > On both cases, the requirement is to pass a framebuffer between two entities, > > and not a video stream. It may not even be a framebuffer. In many cases you'll pass a framebuffer or some memory target (in DRI think probably a GEM handle), in fact in theory you can do much of this now. > > use a buffer that were filled already by the camera. Also, the V4L2 camera > > driver can't re-use such framebuffer before being sure that both consumers > > has already stopped using it. You also potentially need fences which complicates the interface somewhat. > The use case above isn't even possible without copying. At least, I don't see a > way, unless the GPU buffer is non-destructive. In that case you can give the > frame to the GPU, and when the GPU is finished you can give it to the encoder. > I suspect that might become quite complex though. It's actually no different to giving a buffer to the GPU some of the time and the CPU other bits. In those cases you often need to ensure private ownership each side and do fencing/cache flushing as needed. > Note that many video receivers cannot stall. You can't tell them to wait until > the last buffer finished processing. This is different from some/most? sensors. A lot of video receivers also keep the bits away from the CPU as part of the general DRM delusion TV operators work under. That means you've got an object that has a handle, has operations (alpha, fade, scale, etc) but you can never touch the bits. In the TV/Video world not unsurprisingly that is often seen as the 'primary' frame buffer as well. You've got a set of mappable framebuffers the CPU can touch plus other video sources that can be mixed and placed but the CPU can only touch the mappable objects that form part of the picture. Alan _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
