Intel driver 1.3.2

Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
1.3.3.pre1 for development

Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
Check the pointer against NULL

The issue is reported by Klockwork

Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit 80d1f89388c9cb70218cd759592d2167c8845322)
Define i965_CreateSurfaces in header file explicitly to avoid multiple declaration

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
(cherry picked from commit 8b3945aa5df443e93a3f5e6e97dffb1574e2a936)
h264: Add the macros for MVC profiles to keep backward compatibility with libva 1.3.1

It is a part of 1f244834dedb7b46863b315a898d8649d01c5f58 on staging

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
MVC: CODEC_H264_MVC defination and relatived properties check

Signed-off-by: Li Xiaowei <xiaowei.a.li@intel.com>
(cherry picked from commit 7d1ddfd3646f35f306f38bfabef6af9b2ebb19f4)

Conflicts:
	src/i965_drv_video.c
encoder: MVC: Add support for MVC profiles

This is a part of bd630edd844b88ea543a027654db296ff7da16cd on staging

Signed-off-by: Li Xiaowei <xiaowei.a.li@intel.com>
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
decoder: h264: don't deallocate surface storage of older frames.

Drop the optimization whereby surfaces that are no longer marked as
reference and that were already displayed are to be destroyed. This
is wrong mainly for two reasons:

1. The surface was displayed... once but it may still be needed for
   subsequent operations like displaying it again, using it for a
   transcode pipeline (encode) for instance, etc.

2. The new set of ReferenceFrames[] correspond to the active set of
   reference frames used for decoding the current slice. In presence
   of Multiview Coding (MVC), that could correspond to the current
   view, in view order index, but the surface may still be needed
   for decoding the next view with the same view_id, while also
   decoding other views with another set of reference frames for them.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
(cherry picked from commit 77af916b44da04e3424490506a7e5bef39c80c7c)
decoder: h264: allocate reference frames earlier, if needed.

Sometimes, a dummy frame comes from the codec layer and it is used
as a reference, per the comment in the existing code. Even though
this looks suspicious, keep this criterion but make sure to try
allocating the VA surface, if needed, earlier in the function that
sanity checks the parameters for decoding the current frame.

This makes it possible to fail at a much earlier time, and actually
make it possible to return a sensible error code to the upper layer.

Also fix the reference_objects[] array elements to be an exact 1:1
match for ReferenceFrames[] array elements, including possible but
unlikely holes in it. The former array holds object_surface structs
corresponding to the VA surfaces present in the ReferenceFrames[]
array and identified by VAPictureH264.picture_id.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
(cherry picked from commit 5a12ccda3f77d03b6ffa8249d607c03e4dc8161f)
decoder: h264: simplify and optimize reference frame store updates.

Simplify and optimize the update process of the reference frame store.
Use less iterations to look up existing objects. Use a cache to store
the free'd slots.

Prerequisite: the reference_objects[] array was previously arranged in
a way that the element at index i is exactly the object_surface that
corresponds to the VA surface identified by the VAPictureH264.picture_id
located at index i in the ReferenceFrames[] array.

Theory of operations:

1. Obsolete entries are removed first, i.e. entries in the internal DPB
   that no longer have a match in the supplied ReferenceFrames[] array.
   That obsolete entry index is stored in a local cache: free_slots[].

2. This cache is completed with entries considered as "invalid" or "not
   present", sequentially while traversing the frame store for obsolete
   entries. At the end of this removal process, the free_slots[] array
   represents all possible indices in there that could be re-used for
   new reference frames to track.

3. The list of ReferenceFrames[] objects is traversed for new entries
   that are not already in the frame store. If an entry needs to be
   added, it is placed at the index obtained from the next free_slots[]
   element. There is no need to traverse the frame store array again,
   the next available slot can be known from that free_slots[] cache.

v2: dropped the superfluous "found" variable [Yakui]
v3: renamed "free_slots" array to "free_refs", which now holds
  GenFrameStore entries

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
(cherry picked from commit 70ecad1264255123df99b472891e8ee90399013c)
decoder: h264: fix submission of AVC_REF_IDX_STATE command.

If the RefPicListX[] entry has no valid picture_id associated to it,
then set the resulting state to 0xff. If that entry has no surface
buffer storage either, then compose a valid state that maps to the
first item in the reference frames list, as mandated by the PRM.

v2: dropped the superfluous "found" variable [Yakui]

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
(cherry picked from commit 151b8851c3a9309e87712651a3697e20a7bdb6c9)
decoder: h264: factor out look ups for VA/H264 picture info.

Add new avc_find_picture() helper function to search for a VAPictureH264
struct based on the supplied VA surface id.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
(cherry picked from commit 3f4f9fc2893af24b7e88f44b6350a5a74d49f0c2)
decoder: h264: enable Picture ID Remapping on Haswell and newer.

Fill and submit MFX_AVC_PICID_STATE commands to Gen7.5+ hardware.
This optimizes the management of the DPB as the binding array can
now contain entries in any order. This also makes it possible to
support H.264 MultiView High profiles, with any particular number
of views.

v2: added more comments for clarity, removed an assert [Yakui]

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
(cherry picked from commit 8dfdf10612c726b60ecd5b61eee2b7d6a520bb33)
decoder: h264: expose the set of supported MVC profiles.

H.264 MVC decoding support is defined as follows:
- Stereo High profile on Sandybridge and newer ;
- Multiview High profile on Haswell and newer.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
(cherry picked from commit 1f244834dedb7b46863b315a898d8649d01c5f58)

Conflicts:
	src/i965_device_info.c
	src/i965_drv_video.c
	src/va_backend_compat.h
decoder: MVC chroma formats

This is a part of fa469f74227a7b4e0e6f882c488132eaa9c44417 on staging

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
render: don't deallocate surface storage of displayed frames.

Keep the VA surface storage live until it is explicitly scheduled
for destruction through vaDestroySurfaces() interface. Otherwise,
subsequent vaPutSurface() calls would have no effect.

This fixes various use cases like: display of interlaced frames
that are not marked for reference, multiple rendering to Pixmap
for EXT_texture_from_pixmap and more precisely interlaced streams.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
(cherry picked from commit a840e6403071d397a33e127e8058881a3ef50077)
surface: drop SURFACE_DISPLAYED flag.

The optimization by which the VA surface storage is deallocated after
it is displayed and not used for reference or vaDeriveImage() purposes
cannot be implemented safely. We need to honour explicit lifetimes
defined by the upper codec layer.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
(cherry picked from commit 84926ace7a2c5b88df1ada167a1c273128469aad)
decoder: h264: improve AVC_REF_IDX_STATE for MVC.

Each Reference List Entry has Bit 6 set to one if the reference
picture is to be used as a long-term reference picture. However,
the H.264 standard, and subsequently the VA-API specs, makes it
possible to mark the picture as "used for short-term reference",
as "used for long-term reference", or even none of those flags.

This means we have to handle a minimum of 3 states. This doesn't
fit the range of a single bit. Let's examine how this could be
fixed from known practices.

There are cases where the picture is added to RefPicListX[] even
if it is not marked as "used for short-term reference" or "used
for long-term reference": MVC with inter-view reference components
or inter-view only reference components [H.8.4]. Ultimately, this
has an incidence on the value of colZeroFlag (8.4.1.2.2). Since
there is no way to program that, and that it depends on the picture
to be marked as "used for short-term reference" or not, then it
looks reasonable to imply Bit 6 (LongTermPicFlag) as a picture
that is *not* "used for short-term reference", i.e. thus including
genuine long-term reference pictures, and those that are neither
long-term reference nor short-term reference pictures.

In practice, this fixes MVCNV-2.264.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
(cherry picked from commit edbdc0e87919d8b7261d882a32b2d3c271660931)
decoder: h264: fix frame store logic for MVC.

In strict MVC decoding mode, when only the necessary set of inter-view
reference pictures are passed to the ReferenceFrames array for decoding
the current picture, we should not re-use a frame store id that might
be needed for decoding another view component in the same access unit.

One way to solve this problem is to track when the VA surface in a
specified frame store id was last referenced. So, a "ref_age" field
is introduced to the GenFrameStore struct and is updated whenever
the surface is being referenced.

Additionally, the list of retired refs candidates (free_refs) is kept
ordered by increasing ref_age. That way, we can immediately know what
is the oldest frame store id to recycle.

Let deltaAge = CurrAge - RefAge:
If deltaAge > 1, we know for sure that the VA surface is gone ;
If deltaAge = 1, the surface could be re-used for inter prediction ;
If deltaAge = 0, the surface could be re-used for inter-view prediction.

The ref_age in each Frame Store entry is always current, i.e. it is
the same for all reference frames that intervened in the decoding
process of all inter view components of the previous access unit. The
age tracks access units.

v2: used a more correct representation of age, instead of POC [Yakui]
v3: minor optimization for detecting changes of access unit [Haihao]

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
(cherry picked from commit 3b5eb0522fbfe1220dcd0c0bb093a93cfc25e22c)
Encoding: Reinitialize CBR bit rate-control parameter to support switch of bitrate under CBR

Tested-By: Sean V Kelley <sean.v.kelley@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
(cherry picked from commit 929c1446a28dbefd9655774f2db3e10f7b631dcf)