[FFmpeg-devel] [PATCH] Added QSV based VPP filter - second try

[wm4]

On Thu, 5 Nov 2015 16:28:30 +0300
Ivan Uskov <ivan.uskov at 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" <sven at 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.
>