Age | Commit message (Collapse) | Author | Files | Lines |
|
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
|
|
V1->V2: Refine the call back function name from hw_codec_hook to preinit_hw_codec
And it is called after VADriverContext is fully initialized. This is based on the comment
from Gwenole Beauchesne.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
|
|
Implement va{Acquire,Release}BufferHandle() hooks so that to allow
VA surface or VA image buffer sharing with thirdparty APIs like EGL,
OpenCL, etc.
v2: made sure to sync bo before export, improved VA buffer type check.
v3: tracked internal resources on acquire, disposed them on release.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
(cherry picked from commit 483bb130925182f2096cd9e6fa5dbae6a55e7764)
|
|
Two encoding quality levels are support on GEN7.
Default quality level is set to be 1, which has better quality,
but higher gpu usage.
The second quality level is set to be 2, which has worse quality but
it has lower gpu usage.
Other platforms support for multi-quality-level will be added later.
v1->v2: 1. follow haihao's comments to init and check quality_level.
2. remove CBR limitation for low quality level.
(Zhao Yakui helps to merge several patches on staging so that it can
be cherry-picked to master)
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
|
|
slice_header based on VAConfigAttribEncPackedHeaders attribute
Currently the packed_slice_header is optional. And it uses the VAEncSliceParameterBuffer
as the delimeter to decide how to insert the packed rawdata/slice_header
for one slice. This is not convenient under some scenario. For example: some
user hope to be more flexible. When the user is responsible for generating the
packed slice_header, it hopes to use the packed slice_header as the delimeter
to determine how to inser the packed rawdata/slice_header for the given slice.
So the VAConfigAttribEncPackedHeaders attriburation of encoding_context is
used to decide which kind of delimeter.
a. When the VAEncPackedSlice is set when calling vaCreateConfig, it will use
the packed slice_header as delimeter. Of course the packed rawdata should be
parsed before the packed slice_header for one given slice. For exmaple:
for the slice 0: the packed rawdata should be parsed before paring the first
packed slice_header. After one packed slice_header is parsed, it will start
to parse the corresponding data for a new slice.
b. When the VAEncPackedSlice is not set when calling vaCreateConfig, it will
use the VAEncSliceParameterBuffer as delimeter.
V1->V2: Return an error instead of only complaining warning message when packed
slice_header is missing for some slice under the VAEncPackedSlice mode. This
is the suggestion from Gwenole and Sreerenj Balachandran.
Signed-off-by: Zhao, Yakui <yakui.zhao@intel.com>
(cherry picked from commit 9d49a6d693aa6c862467a4a879bc86d9cb98dbe5)
|
|
rawdata/slice_header data
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
(cherry picked from commit 56715c893fa87e2d3af2938b9202d75cdc79a8fd)
|
|
Under some encoding scenario, the user hopes to generate the packed slice
header data by themself and then the driver can insert the passed slice
header packed data into the coded clip.
1.The VA_ENC_PACKED_HEADER_SLICE flag is exported and it is treated as optional.
This is to say: if packed slice header data is passed, it will be
inserted directly. If no packed slice header data is passed, the driver will
help to generate it.
2.Another restriction is that the packed slice header data is inserted after
the packed rawdata for one slice. That is to say: If it needs to insert the
packed rawdata and slice header data, the packed rawdata will be inserted
firstly(This is handled by the driver).
Signed-off-by: Zhao, Yakui <yakui.zhao@intel.com>
(cherry picked from commit 00111e8a8bfa67b971419b72577eaa1b9f47bc34)
Conflicts:
src/gen75_mfc.c
src/gen8_mfc.c
|
|
Under some encoding scenario, the user-space application hopes that the driver
can insert the passed packed rawdata into the coded clip. But the insertion of
packed rawdata is related with the slice. So some data structures are added so
that it can store how the packed rawdata is inserted into the coded clip
per-slice.
Signed-off-by: Zhao, Yakui <yakui.zhao@intel.com>
(cherry picked from commit 65727b1868f01d836659396724b83d2992656242)
|
|
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)
|
|
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
|
|
Signed-off-by: Li Xiaowei <xiaowei.a.li@intel.com>
(cherry picked from commit 7d1ddfd3646f35f306f38bfabef6af9b2ebb19f4)
Conflicts:
src/i965_drv_video.c
|
|
declaration
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
(cherry picked from commit 8b3945aa5df443e93a3f5e6e97dffb1574e2a936)
|
|
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>
|
|
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>
|
|
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>
|
|
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)
|
|
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)
|
|
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
|
|
This is helpful to avoid the typo error when using VA_FOURCC(A, B, C, D).
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
(cherry picked from commit ab3e02d63fe672e3f81631f2beb5bc2b7ab17af0)
|
|
a return value is expected when assert is disabled.
Signed-off-by: Zhao Halley <halley.zhao@intel.com>
(cherry picked from commit 12c81227fd92fe028100af0cb32cc17b7f698b3d)
|
|
It is done by two VASurfaceAttrib:
* one is buffer attribute described by VASurfaceAttribExternalBufferDescriptor.
it covers strides and tiling or not.
* another is buffer type to indicate that the buffer is allocated by va driver.
VASurfaceAttribMemoryType:VA_SURFACE_ATTRIB_MEM_TYPE_VA
Signed-off-by: Zhao Halley <halley.zhao@intel.com>
Reviewed-by: Zhao Yakui <yakui.zhao@intel.com>
(cherry picked from commit 55e63685dc040e3855868b4d7ccb0ac8e1f66690)
|
|
declaration
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
(cherry picked from commit af0687252bfc6f81ff5361feedba7ec8989b3555)
|
|
addressing mode
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73016
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
Tested-by: Mark Lee <mark@markelee.com>
|
|
And check the type before storing misc parameters
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Add comments for width/height, orig_width/orig_height as well
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit f886f24eaaacba9544fa5f6405b7382c686f3a1f)
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit 04ecb6e79f4382d96eb5d4b51733049d420f592a)
|
|
It is easy to result in multithread issue if the rendering code
and video processing code share the same batch buffer
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit ce0984814269e0923f44196e47f1c7cc2dddc55c)
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit 3ab97be8db1b8e55d0d5b95f577863416a87c6ff)
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
(cherry picked from commit a532539cbc7048f5c01b64dfe239f1570123c959)
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Conflicts:
NEWS
configure.ac
src/Makefile.am
src/gen6_mfc.c
src/gen6_mfd.c
src/gen6_vme.c
src/gen6_vme.h
src/gen75_mfc.c
src/gen75_mfd.c
src/gen75_vme.c
src/gen75_vpp_vebox.c
src/gen75_vpp_vebox.h
src/gen7_mfd.c
src/i965_avc_bsd.c
src/i965_decoder.h
src/i965_decoder_utils.c
src/i965_defines.h
src/i965_drv_video.c
src/i965_drv_video.h
src/i965_encoder.c
src/i965_encoder.h
src/i965_output_dri.c
src/i965_post_processing.c
src/i965_post_processing.h
src/i965_render.c
src/i965_structs.h
src/intel_driver.c
src/object_heap.c
src/shaders/post_processing/Common/AYUV_Load_16x8.asm
src/shaders/post_processing/Common/AYUV_Load_16x8.inc
src/shaders/post_processing/Common/Init_All_Regs.asm
src/shaders/post_processing/Makefile.am
src/shaders/post_processing/gen5_6/Common/AYUV_Load_16x8.asm
src/shaders/post_processing/gen5_6/Common/AYUV_Load_16x8.inc
src/shaders/post_processing/gen5_6/Common/Init_All_Regs.asm
src/shaders/post_processing/gen5_6/Common/NV12_Load_8x4.asm
src/shaders/post_processing/gen5_6/Common/RGBX_Load_16x8.asm
src/shaders/post_processing/gen5_6/Common/RGBX_Load_16x8.inc
src/shaders/post_processing/gen5_6/Makefile.am
src/shaders/post_processing/gen5_6/nv12_avs_nv12.g4b.gen5
src/shaders/post_processing/gen5_6/nv12_avs_nv12.g6b
src/shaders/post_processing/gen5_6/nv12_dn_nv12.g4b.gen5
src/shaders/post_processing/gen5_6/nv12_dn_nv12.g6b
src/shaders/post_processing/gen5_6/nv12_dndi_nv12.g4b.gen5
src/shaders/post_processing/gen5_6/nv12_dndi_nv12.g6b
src/shaders/post_processing/gen5_6/nv12_load_save_nv12.g4b.gen5
src/shaders/post_processing/gen5_6/nv12_load_save_nv12.g6b
src/shaders/post_processing/gen5_6/nv12_load_save_pa.g4b.gen5
src/shaders/post_processing/gen5_6/nv12_load_save_pa.g6b
src/shaders/post_processing/gen5_6/nv12_load_save_pl3.g4b.gen5
src/shaders/post_processing/gen5_6/nv12_load_save_pl3.g6b
src/shaders/post_processing/gen5_6/pa_load_save_nv12.g4b.gen5
src/shaders/post_processing/gen5_6/pa_load_save_nv12.g6b
src/shaders/post_processing/gen5_6/pa_load_save_pl3.g4b.gen5
src/shaders/post_processing/gen5_6/pa_load_save_pl3.g6b
src/shaders/post_processing/gen5_6/pl3_load_save_nv12.g4b.gen5
src/shaders/post_processing/gen5_6/pl3_load_save_nv12.g6b
src/shaders/post_processing/gen5_6/pl3_load_save_pa.g4b.gen5
src/shaders/post_processing/gen5_6/pl3_load_save_pa.g6b
src/shaders/post_processing/gen5_6/pl3_load_save_pl3.g4b.gen5
src/shaders/post_processing/gen5_6/pl3_load_save_pl3.g6b
src/shaders/post_processing/gen7/EOT.g4a
src/shaders/post_processing/gen7/Makefile.am
src/shaders/post_processing/gen7/PA_AVS_Buf_0.g4a
src/shaders/post_processing/gen7/PA_AVS_Buf_1.g4a
src/shaders/post_processing/gen7/PA_AVS_Buf_2.g4a
src/shaders/post_processing/gen7/PA_AVS_Buf_3.g4a
src/shaders/post_processing/gen7/PL2_AVS_Buf_0.g4a
src/shaders/post_processing/gen7/PL2_AVS_Buf_1.g4a
src/shaders/post_processing/gen7/PL2_AVS_Buf_2.g4a
src/shaders/post_processing/gen7/PL2_AVS_Buf_3.g4a
src/shaders/post_processing/gen7/PL3_AVS_Buf_0.g4a
src/shaders/post_processing/gen7/PL3_AVS_Buf_1.g4a
src/shaders/post_processing/gen7/PL3_AVS_Buf_2.g4a
src/shaders/post_processing/gen7/PL3_AVS_Buf_3.g4a
src/shaders/post_processing/gen7/Save_AVS_NV12.g4a
src/shaders/post_processing/gen7/Save_AVS_PA.g4a
src/shaders/post_processing/gen7/Save_AVS_PL3.g4a
src/shaders/post_processing/gen7/Save_AVS_RGB.g4a
src/shaders/post_processing/gen7/Set_AVS_Buf_0123_BGRA.g4a
src/shaders/post_processing/gen7/Set_AVS_Buf_0123_PL2.g4a
src/shaders/post_processing/gen7/Set_AVS_Buf_0123_PL3.g4a
src/shaders/post_processing/gen7/Set_AVS_Buf_0123_VUYA.g4a
src/shaders/post_processing/gen7/Set_AVS_Buf_0123_VYUA.g4a
src/shaders/post_processing/gen7/Set_Layer_0.g4a
src/shaders/post_processing/gen7/VP_Setup.g4a
src/shaders/vme/Makefile.am
src/shaders/vme/inter_frame_haswell.asm
src/shaders/vme/inter_frame_haswell.g75b
src/shaders/vme/intra_frame_haswell.asm
src/shaders/vme/intra_frame_haswell.g75b
src/shaders/vme/vme75.inc
src/shaders/vme/vme7_mpeg2.inc
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
In addition, uses the corresponding surface object directly.
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|
|
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
|