Age | Commit message (Collapse) | Author | Files | Lines |
|
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)
|
|
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)
|
|
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)
|
|
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>
|
|
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
|
|
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)
|
|
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)
|
|
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)
|
|
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)
|
|
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)
|
|
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)
|
|
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>
|
|
Signed-off-by: Li Xiaowei <xiaowei.a.li@intel.com>
(cherry picked from commit 7d1ddfd3646f35f306f38bfabef6af9b2ebb19f4)
Conflicts:
src/i965_drv_video.c
|
|
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>
|
|
declaration
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
(cherry picked from commit 8b3945aa5df443e93a3f5e6e97dffb1574e2a936)
|
|
The issue is reported by Klockwork
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit 80d1f89388c9cb70218cd759592d2167c8845322)
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Otherwise it will cause the incorrect intra-prediction for encoding on
Broadwell.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
(cherry picked from commit 20bee4c3cb478702155df1779f24ec483aeab059)
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
VA_INTEL_DEBUG_ASSERT decides assert() is enabled or not
VA_INTEL_DEBUG_BENCH decides skipping swapbuffer in dri output
(cherry picked from commit 60413182f66c44781456e827b439e98f21cfae4c)
|
|
Scaling is done on each 16x16 block. The shader for scaling
might write pixels out-of-rectangle if the rectangle width/height
isn't aligned to 16.
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit d560387cc819a31791c2a30026473c9bd8786f07)
|
|
v2: bpp[] is in unit of bits
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit d415357f25fc01b96592ba29ba95da9d6dc82ff3)
|
|
and hold all supported fourcc in an array
v2: bpp[] in bit and fix the vertical factor for 411P (Yakui)
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit 1de3a2cdc8c3f8b2f6191c0f114fa1167f40f2ec)
Conflicts:
src/i965_drv_video.c
|
|
Sometimes pending datas are added in slice data buffer, however
HW requires slice data length excludes pending datas, otherwise
the behavior is undefined
https://bugs.freedesktop.org/show_bug.cgi?id=77041
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit a9004e6c5c7f33cd1e33e4dab92a5a0017714bbd)
|
|
Signed-off-by: Sebastian Ramacher <sramacher@debian.org>
Reviewed-by: Zhao, Yakui <yakui.zhao@intel.com>
(cherry picked from commit ca1acd54eb59eadabfb40a4b61df2e8968b5e00d)
|
|
Signed-off-by: Sebastian Ramacher <sramacher@debian.org>
Reviewed-by: Zhao, Yakui <yakui.zhao@intel.com>
(cherry picked from commit e9e9b55c769a6c0b90d6af5d89a6baf4c6f742be)
|
|
Set the right surface states for reference, STMM and output surface,
fix the shader as well
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
Tested-By: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
(cherry picked from commit 1d1b8da1284f7f918733db79428f09af38d7e14a)
Conflicts:
src/i965_post_processing.c
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=79065
The regression is caused by commit 42258e1
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit 0523c58148e9496927f2c3fa9a641885a0350d0f)
|
|
It is always true or false
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit 42258e128f19b93aa102672d5f61eb73d9f9808f)
|
|
Broadwell now uses a unique DMV buffer, irrespective of any field
coding mode. The dmv_buffer is not used, so it doesn't need to be
allocated at all.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
|
|
Don't allocate tiled surfaces on Ironlake platforms and earlier, stick
to linear surfaces.
This is a regression from 6d76944.
Reported-by: Haihao Xiang <haihao.xiang@intel.com>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
|
|
Optimize support for grayscale surfaces in two aspects: (i) space
by only allocating the luminance component ; (ii) speed by avoiding
initialization of the (now inexistent) chrominance planes.
Keep backward compatibility with older codec layers that only
supported YUV 4:2:0 and not grayscale formats properly.
v2: fix check for extra H.264 chroma formats [Haihao]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
|
|
Add new avc_ensure_surface_bo() helper function to factor out the
allocatiion and initialization processes of the reconstructed VA
surface buffer stores.
Keep preferred native format (NV12) and initialize chroma values
to 0.0 (0x80) when needed for "fake" grayscale (Y800) surfaces
implemented on top of existing NV12.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
|
|
If the hardware supports JPEG decoding, then we have to expose the
right set of chroma formats for the output (decoded) VA surface. In
particular, we could support YUV 4:0:0, 4:1:0, 4:2:2 and 4:4:4.
v2: export support for YUV 4:0:0 (grayscale) too [Haihao]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
|
|
Only validate the user-defined chroma format (VAConfigAttribRTFormat)
attribute, if any. Don't override it. i.e. append a pre-defined value
only if it was not defined by the user beforehand.
Propertly return VA_STATUS_ERROR_UNSUPPORTED_RT_FORMAT if the supplied
chroma format is not supported.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
|
|
Factor out code to validate profile/entrypoint per the underlying
hardware capabilities. Also fix vaGetConfigAttributes() to really
validate the profile/entrypoint pair.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
|
|
Introduce a new i965_destroy_surface_storage() helper function to
unreference the underlying GEM buffer object, and any associated
private data, if any.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
|
|
Fix size of the allocated buffer used to represent grayscale (Y800)
surfaces. Only the luminance component is needed, thus implying a
single plane.
Likewise, update render routines to only submit the first plane.
The existing render kernels readily only care about that single
plane.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
|
|
Some MPEG-2 videos set progressive_frame to 1 and set
frame_pred_frame_dct to 0, which is not conformed to MPEG-2 spec.
bottom field may be used to form prediction if frame_pred_frame_dct is
0. Previously the bottom field is excluded from the frame store list
https://bugs.freedesktop.org/show_bug.cgi?id=73424
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit b3031d16b1ea9ef2ab95bc09e59f0db5214a1125)
|
|
pitch must be 64 at least for linear surface for most functions on IVB/HSW/BDW
such VEBOX, Data port media read/write
https://bugs.freedesktop.org/show_bug.cgi?id=72522
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit 57db5c2524f4e3cb6ae2301bddfdf1c40cdbb626)
|
|
Directly check the flag of has_vpp in codec_info
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit 1c4d3468229797e787f4b99b0729baf90a115a1d)
Conflicts:
src/gen8_post_processing.c
src/i965_post_processing.c
|
|
It is to reduce the usage of IS_GENxxx() as well.
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit 77b6a72504d917af9335ab94f6ecbefb8b087206)
|
|
It is to reduce the usage of IS_GENxxx()
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit f150fbf444ca63b5e9c3e8f7e17aa3386f7061fa)
|
|
Now it can directly use the information in intel_device_info instead of
checking the pci id.
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit f1b3f83953cd5f6e39900d98b4858a7cb825dee0)
Conflicts:
src/gen8_post_processing.c
src/i965_post_processing.c
src/intel_driver.h
|
|
Instead directly use the value stored in intel_device_info
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit 6ba787b29e4bcebdceda52906e33cb84f24a63b5)
|
|
Instead directly use the value stored in intel_device_info
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit a0fe5a6262f9ff1398a512c83d193556bbd0eae9)
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit 2518c1e741cb21c5412a4b5252ebe861a52c2900)
|
|
To store statically known device information
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit eb014a09fde988ba3ed2d2be6e8d6f0c650d281e)
|
|
The redundant code will be removed soon.
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit d20db5984989626728f62eb3e02b60093d914d01)
Conflicts:
src/i965_drv_video.c
|