Hi Gerd, On Thu, Dec 19, 2019 at 10:12 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > Hi, > > > > However that still doesn't let the driver know which buffers will be > > > dequeued when. A simple example of this scenario is when the guest is > > > done displaying a frame and requeues the buffer back to the decoder. > > > Then the decoder will not choose it for decoding next frames into as > > > long as the frame in that buffer is still used as a reference frame, > > > even if one sends the drain request. > > It might be that I'm getting your point wrong, but do you mean some hardware > > can mark a buffer as ready to be displayed yet still using the underlying > > memory to decode other frames? > > Yes, this is how I understand Tomasz Figa. > > > This means, if you occasionally/intentionally > > write to the buffer you mess up the whole decoding pipeline. > > And to avoid this the buffer handling aspect must be clarified in the > specification. Is the device allowed to continue using the buffer after > finishing decoding and completing the queue request? If so, how do we > hand over buffer ownership back to the driver so it can free the pages? > drain request? How do we handle re-using buffers? Can the driver > simply re-queue them and expect the device figures by itself whenever it > can use the buffer or whenever it is still needed as reference frame? The device shouldn't be able to access buffers after it completes a queue request. The device can touch buffer contents from when a queue request is sent until the device responds it. In contrast, the driver must not modify buffer contents in that period. Regarding re-using, the driver can simply re-queue buffers returned by the device. If the device needs a buffer as reference frame, it must not return the buffer. I'll describe this rule in the next version of the patch. Best regards, Keiichi > > cheers, > Gerd >
