On Thu, 5 Nov 2015 16:28:30 +0300
Ivan Uskov <ivan.us...@nablet.com> wrote:
> Hello wm4,
>
> Thursday, November 5, 2015, 3:42:30 PM, you wrote:
>
> w> On Thu, 5 Nov 2015 12:49:50 +0100
> w> "Sven Dueking" <s...@nablet.com> wrote:
>
> >> > > + } else if (ret == MFX_WRN_DEVICE_BUSY) {
> >> > > + av_usleep(500);
> >> >
> >> > What. Use proper event-based waiting.
> It is not possible.
> >>
> >> That´s the same behavior as we have in the qsv encoder and decoder.
> >> And as far as I know this is how Intel recommends to handle this.
>
> w> That's just ridiculous. Can you send some hate-mail to Intel and tell
> w> them what a bad idea this is? Half a millisecond is an eternity for a
> w> CPU. What if the device is blocked only for 10 microseconds? Then it
> w> will waste time by spending 490 microseconds idly.
> 1. Please remember we use GPU, not CPU.
That makes it even worse, because the CPU could literally be entirely
idle.
> 2. 500us means that even we will get MFX_WRN_DEVICE_BUSY at every frame we
> will able to achieve ~2000fps performance. It looks enough
> performance level for any practical applications.
Only if all other CPU processing takes 0 microseconds.
> 3. In real life MFX_WRN_DEVICE_BUSY does appear when GPU really busy by
> other tasks. So nothing bad will appear if one thread/process will sleep for
> 500us to make another thread complete its work.
>
> w> Software engineers recognized that polling is a bad idea half a century
> w> ago. Why can't Intel do this right?
> May be because it is complex to organize event-polling when calculations
> performs in GPU?
Even just making the call blocking would be 1. easier, 2. more
efficient (because it will idle only as long as needed).
> w> Or does MFX have some sort of async mode that works without polling?
> Does NOT. I'm sorry but we forced to use this way, since it is by QSV
> design.
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
