On Mon, Jan 25, 2016 at 08:01:02PM +0100, Hendrik Leppkes wrote: > On Mon, Jan 25, 2016 at 7:50 PM, Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > On Mon, Jan 25, 2016 at 04:39:49PM +0100, Hendrik Leppkes wrote: > >> On Mon, Jan 25, 2016 at 1:28 PM, Ronald S. Bultje <rsbul...@gmail.com> > >> wrote: > >> > Hi, > >> > > >> > On Mon, Jan 25, 2016 at 4:01 AM, wm4 <nfx...@googlemail.com> wrote: > >> > > >> >> On Sun, 24 Jan 2016 20:03:01 -0500 > >> >> "Ronald S. Bultje" <rsbul...@gmail.com> wrote: > >> >> > >> >> > Hi, > >> >> > > >> >> > On Sun, Jan 24, 2016 at 6:49 PM, Hendrik Leppkes <h.lepp...@gmail.com> > >> >> > wrote: > >> >> > >> >> > >> >> > > Unfortunately that doesn't alleviate the other issues, like the > >> >> > > complexity needed in the decoders during frame threading, or the > >> >> > > extra > >> >> > > resources needed (extra image surfaces for every thread). > >> >> > > > >> >> > > >> >> > So, the extra code is just in the decoders, which already need it > >> >> > anyway > >> >> > (because they implement frame-mt), right? Or do hwaccels need extra > >> >> > code > >> >> > also? > >> >> > > >> >> > The extra resources aren't a big deal IMO. Memory use isn't typically > >> >> > a > >> >> big > >> >> > issue, we're adding a fw kb extra for contexts but practically all > >> >> > memory > >> >> > is in framebuffers regardless. > >> >> > >> >> It's can be a big deal for hardware decoding, because hw surfaces > >> >> might be a more constrained resource than system RAM. Also, you often > >> >> have to preallocate _all_ surfaces you're going to use, so you'll have > >> >> to add the exact number of additionally needed surfaces to the > >> >> preallocation. > >> > > >> > > >> > If only one thread is active, the rest never has to be inited and thus > >> > contains no surfaces (or framebuffers, or anything), right? If not, that > >> > should be a trivial win. > >> > > >> > >> If you can implement it like this, ie. only make one single thread do > >> the work, that would also avoid a bunch of the complexity with copying > >> contexts around and avoiding multiple init calls of the hwaccel. > >> On top of that, avoid the extra resource requirements and the delay > >> inherent to frame threading otherwise, since no extra frames are > >> "cached" inside the other worker threads. > > > > is there no hwaccel that (can) work(s) with MT ? > > iam bringing that up here before code is unconditionally removed that > > might be needed for such case > > > > Like I explained in an earlier post above, hwaccels don't MT, they > execute async on a worker thread, but never more than one at the same > time. > The only reason someone might potentially see any speed up from using > hwaccel+MT is from the sheer lack of optimizations in > ffmpeg_<dxva2/vdpau>.c. Some very basic pipelining would give the same > speed up, instead of forcing the hardware to sync every frame > immediately as it is right now. > > Thats really all the MT case does today: It adds a "delay", that > allows the hardware internally to work more in parallel, but you don't > need MT to do that, you can just buffer 2-4 output frames before > trying to process them and achieve the exact same speedup. > This behavior was confirmed by an NVIDIA engineer some years ago - the > hardware has several "stages", and for optimal performance you should > keep multiple frames inside the hardware. The decode APIs don't allow > this, so the GPU already returns you a frame while its still being > decoded in a later stage - and once you try to access it, the GPU has > to "sync" the frame and wait until its done. If you just buffer it for > a bit (say a 2 frame ring buffer), this bottleneck goes away and all > is fast.
ok thanks for explaining [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
