[Libva] Ivy bridge PRM and H.264 encoder implementation

[Xiang, Haihao]

On Tue, 2012-07-03 at 21:28 +0100, Joe Bloggsian wrote: 
> It is great that intel have released proper documentation for the Ivy 
> bridge GPU/media engines. Kudos to them; if only all silicon vendors 
> were so progressive!
> 
> In particular it is very interesting to see the detailed information on 
> the VME engine in Vol4 Part2, which seems a much more sophisticated 
> piece of hardware than I expected.
> 
> Comparing the documentation to the even the staging branch of 
> intel-driver (in particular inter_frame.asm). It *appears* that there 
> are significant hardware features that the current encoder 
> implementation might not be using (or could be used better). A couple of 
> examples:
> 
> 1) The search and cost centers of the current implementation appear to 
> always be zero. It seems to me this will firstly be resulting in 
> improper costings for the motion vector selection (mv cost should be 
> relative to an approximation of the predicted motion vectors). Secondly 
> it implies a limitation of max MV that can be found to 16  x, 12 y 
> integer pixels from the origin (not nearly enough for HD video). This 
> seems consistent with the poor MV selection I see in the encoded video. 
> It should be easy (and far better) to set the search and cost centers to 
> (one of the) MVs found in the macroblock to the left as this is on the 
> whole going to be a much better approximation of the predicted MVs, and 
> this would also allow the encoder to find long MVs. One can imagine 
> other even better ways to set the search position.

You are right, the parameters for the search and cost center aren't
optimal. You are welcome to provide patches for it.

> 
> 2)  It appears that none of the early exit options are used; 
> EarlySkipSuccess, IMESuccess, EarlyIMEStop, SkipSuccess, etc. These 
> ought to be a "free" significant performance gain just for setting some 
> registers?

You also need to set threshold for these parameters in the VME message.
Only enabling these features without optimal threshold values may drop
down the quality a lot.

Thanks
Haihao

> 
> Does the above seem reasonable and are there any existing plans to 
> implement these kinds of improvements?
> If not already being worked on - would it be interesting for me to 
> attempt to make changes similar to those I described and provide patches?
> 
> Cheers,
> Bloggsian
> _______________________________________________
> Libva mailing list
> Libva at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libva