vebox: silence compilation warning.

Silence the following compilation warning:
  CC     i965_drv_video_la-gen75_vpp_vebox.lo
gen75_vpp_vebox.c: In function 'bdw_veb_dndi_iecp_command':
gen75_vpp_vebox.c:1537:5: warning: suggest parentheses around arithmetic in operand of '|' [-Wparentheses]

Also simplify the calculation of the VEB_DI_IECP::endingX variable
with existing helper macros.

v2: renamed endingX to width64, which represents the width aligned
  on to 64 columns, dropped obsolete startingX [Yakui]

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vebox: drop magic numbers in filters mask.

Use the existing VPP_{DNDI,IECP}_xxx flags instead of magic numbers.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vebox: fix indication of field ordering in sequence.

VEBOX_DNDI_STATE::dndi_top_first indicates whether the top field is
first in sequence (TFF), or if the bottom field comes first. This is
an indication of the temporal sequence for input frames, available
in the "history" buffer. As such, the correct flag to check against,
from a VA-API perspective, is VA_DEINTERLACING_BOTTOM_FIELD_FIRST.

https://bugs.freedesktop.org/show_bug.cgi?id=72518
https://bugs.freedesktop.org/show_bug.cgi?id=72522

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vebox: fix order of submitted commands.

For each frame, the Intel HD Graphics hardware specification mandates
that the following commands should be submitted, in-order: VEBOX_STATE,
VEBOX_SURFACE_STATE(input), VEBOX_SURFACE_STATE(output), VEB_DI_IECP.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vebox: fix invalid conversion and scaling params order.

The arguments to vpp_surface_convert() were mixed up. i.e. both input
and output surfaces were reversed. Changed the vpp_surface_scaling()
arguments order as well to have more consistent helper functions.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vebox: clean-up frame store initialization.

Rename FRAME_STORE_SUM to FRAME_STORE_COUNT, use existing macros to
determine the number of elements in the frame store array, avoid
duplicate zero initializations.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vebox: factor out initialization of pipeline parameters.

Factor out initialization and validation of pipeline parameters.
In particular, introduce a new gen75_vebox_init_pipe_params() helper
function that initializes the filters mask and ensures the supplied
filters are going to be supported.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vebox: robustify frame store surface storage allocations.

Clean-up frame store surface storage allocation, rename the helper
function to gen75_vebox_ensure_surfaces_storage() and make it more
robust to allocation errors. i.e. propagate them up right away.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vebox: factor out deinterlacing code, drop broken MADI/MCDI support.

Completely rework the VEBOX code to factor out and improve the various
deinterlacing algorithms in particular. Introduce temporary variables
that are going to be live for the current VPP processing call.

Drop MADI/MCDI support for now, as it never really worked.

Initial focus was to definitively fix first vs. second field detection
code, thus allowing for multiple VEBOX calls with an additional format
conversion away.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vebox: add support for advanced deinterlacing.

Reintegrate Motion Adaptive Deinterlacing (MADI) and Motion Compensated
Deinterlacing (MCDI) support. This is totally reworked so that to allow
for bob-deinterlacing if no previous frame was supplied, improve global
robustness, and ensure that the right surface storage are used, which
is the most important fix.

https://bugs.freedesktop.org/show_bug.cgi?id=79698
https://bugs.freedesktop.org/show_bug.cgi?id=79528

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vebox: use Y-tiling for internal VEBOX surfaces.

Always use Y-tiling in native surface format for performance reasons.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vebox: fix memory leak of VEBOX state tables.

This occurs after a while (~10-20 minutes) when video processing is
used, and deinterlacing in particular. At some point, GPU memory is
exhausted and we start error'ing out to upper layers.

https://bugzilla.gnome.org/show_bug.cgi?id=731460#c31

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vebox: fix denoising when IECP is enabled.

If IECP is enabled, for instance when color conversion is performed
or ProcAmp adjustments are applied, the ultimate denoised output with
additional processing operations applied is the Current Output frame,
not the plain Current Denoised Output frame.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vpp: fix adaptive filter for all channels flag (< Haswell).

The "Adaptive filter for all channels" bit for AVS on Ironlake up to
including Ivybridge/Baytrail is not located in DW137, but rather in
the first table of coefficients for chroma samples.

Thus, split the SAMPLER_STATE_8x8 message DW137 into parts relevant
to Haswell and newer generations ("hsw"), and to the legacy platforms
down to Ironlake ("ilk").

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vpp: fix AVS coefficients for Broadwell.

Fix AVS filter coefficients for Broadwell. At least, we now address
the expected entry in the table but the actual value is still not
viable enough.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vpp: factor out calculation of AVS coefficients.

Split calculation of AVS coefficients into separate helper functions
in view to supporting alternate algorithms, but we stick to bilinear
interpolation for now.

Actually fix bilinear filtering coefficients if the sharp 8x8 filter
is used. This is still disabled by default though.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vpp: add support for high-quality scaling.

Add support for high-quality scaling during video processing. This is
enabled with the VA_FILTER_SCALING_HQ filter flag. The algorithm used
for that is based on a Lanczos convolution kernel: 3 lobes on either
side for luma samples, and 2 lobes on either side for chroma samples.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vpp: validate AVS filter coefficients for debugging purposes.

Make sure the newly calculated filter coefficients fall into the HW
accepted range of values. This normally should not be an issue with
the current configuration / scaling algorithms though.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vpp: cache calculation of AVS coefficients.

If scaling parameters don't change, i.e. if the same scaling algorithm
and factors are used, there is no point in calculating the filter
coefficients again. So, just cache them into the existing AVS context.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
vpp: drop internal postprocessing (I965_PP_xxx) flags.

Exclusively use VA-API defined video processing flags, instead of yet
redefining another set with limited use. This means that we can use
scaling, colorspace and picture structure flags as is, without an extra
layer of conversion.

Drop I965_PP_FLAG_MCDI (motion compensated deinterlacing), which was
never set. Dropped the associated dead code, which was never used. And,
anyway, advanced deinterlacing modes shall go through the explcit VPP
interfaces.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>