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.
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?
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
