Gerd Knorr wrote:
...
> > > Remaining overhead is page table lookups + (for bt848) risc code
> > > generation. Even that can be reduced. We could use a flag for that.
> > > If a application plans to reuse that buffer some hint flag can be set,
> > > and the driver can keep the buffer locked down then. Not forever
> > > (that would allow a nice DoS), but for - say - a second. Long enouth
> > > that we don't have to lock it again if the app does streaming
> > > capture.
> > >
> > > Gerd
> >
> > Now this is starting to look a lot uglier than simply modifying the
> > REQBUFS semantics to allow freeing of the buffers explicitly (which you
> > still require anyway).
>
> The point isn't that you save the REQBUFS(0). The point is we can be more
> flexible (the application _can_ reuse buffers, but this is not _required_)
> without a major performance hit (the application can hint the driver that
> it plans to reuse the buffer and it is worth keeping it locked in memory
> to save some CPU time / avoid swapout / whatever).
OK - then how about keep the REQBUFS(0) (or something similar), and
scrap this stuff about locking down a buffer for 1 second, etc. That is
starting to look like a horrible kludge, with a lot that can go wrong.
Could you possibly include a short draft of your spec, just so that I
can see it all together (possibly add how you want to handle multiple
planes) - I would really appreciate it.
Thanks,
-justin
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
