Hi Nicolas, On Sat, Oct 27, 2018 at 6:38 PM Nicolas Dufresne <nicolas@xxxxxxxxxxxx> wrote: > > 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 <pza@xxxxxxxxxxxxxx> 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. Would such REQBUFS dance be really needed? Couldn't one simply try reqbufs(0) when it's really needed and if it fails then do the copy, otherwise just proceed normally? Best regards, Tomasz
