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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/libva _______________________________________________ Libva mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libva
