Le lundi 03 avril 2017 à 15:46 -0400, Javier Martinez Canillas a écrit : > > The problem is that adding implicit fences changed the behavior of > > the ioctls, causing gstreamer to wait forever for buffers to be ready. > > > > The problem was related to trying to make user-space unaware of the implicit > fences support, and so it tried to QBUF a buffer that had already a pending > fence. A workaround was to block the second QBUF ioctl if the buffer had a > pending fence, but this caused the mentioned deadlock since GStreamer wasn't > expecting the QBUF ioctl to block. That QBUF may block isn't a problem, but modern userspace application, not just GStreamer, need "cancellable" operations. This is achieved by avoiding blocking call that cannot be interrupted. What is usually done, is that we poll the device FD to determine when it is safe to call QBUF in a way that it will return in a finit amount of time. For the implicit fence, it could not work, since the driver is not yet aware of the fence, hence cannot use it to delay the poll operation. Though, it's not clear why it couldn't wait asynchronously like this RFC is doing with the explicit fences. In the current RFC, the fences are signalled through a callback, and QBUF is split in half. So waiting on the fence is done elsewhere, and the qbuf operation completes on the fence callback thread. Nicolas
Attachment:
signature.asc
Description: This is a digitally signed message part
