Le lundi 22 octobre 2018 à 12:37 +0900, Tomasz Figa a écrit : > Hi Philipp, > > On Mon, Oct 22, 2018 at 1:28 AM Philipp Zabel wrote: > > > > On Wed, Oct 03, 2018 at 05:24:39PM +0900, Tomasz Figa wrote: > > [...] > > > > Yes, but that would fall in a complete redesign I guess. The buffer > > > > allocation scheme is very inflexible. You can't have buffers of two > > > > dimensions allocated at the same time for the same queue. Worst, you > > > > cannot leave even 1 buffer as your scannout buffer while reallocating > > > > new buffers, this is not permitted by the framework (in software). As a > > > > side effect, there is no way to optimize the resolution changes, you > > > > even have to copy your scannout buffer on the CPU, to free it in order > > > > to proceed. Resolution changes are thus painfully slow, by design. > > > > [...] > > > Also, I fail to understand the scanout issue. If one exports a vb2 > > > buffer to a DMA-buf and import it to the scanout engine, it can keep > > > scanning out from it as long as it want, because the DMA-buf will hold > > > a reference on the buffer, even if it's removed from the vb2 queue. > > > > REQBUFS 0 fails if the vb2 buffer is still in use, including from dmabuf > > attachments: vb2_buffer_in_use checks the num_users memop. The refcount > > returned by num_users shared between the vmarea handler and dmabuf ops, > > so any dmabuf attachment counts towards in_use. > > Ah, right. I've managed to completely forget about it, since we have a > downstream patch that we attempted to upstream earlier [1], but didn't > have a chance to follow up on the comments and there wasn't much > interest in it in general. > > [1] https://lore.kernel.org/patchwork/patch/607853/ > > Perhaps it would be worth reviving? In this patch we should consider a way to tell userspace that this has been opt in, otherwise existing userspace will have to remain using sub-optimal copy based reclaiming in order to ensure that renegotiation can work on older kernel tool. At worst someone could probably do trial and error (reqbufs(1)/mmap/reqbufs(0)) but on CMA with large buffers this introduces extra startup time. > > Best regards, > Tomasz