On Wo, 2024-04-03 at 20:21 +0100, Mark Thompson wrote:
> On 28/03/2024 02:17, Xiang, Haihao wrote:
> > From: Haihao Xiang <haihao.xi...@intel.com>
> >
> > libva2 doesn't require a fixed surface-array any more, but some
> > driver/hardware combinations which rely on this are still used. To
> > reduce the impact to users, add a quirk for the driver/hardware
> > combination which supports dynamic surface pool.
> >
> > Signed-off-by: Haihao Xiang <haihao.xi...@intel.com>
> > ---
> > libavutil/hwcontext_vaapi.c | 7 +++++++
> > libavutil/hwcontext_vaapi.h | 6 ++++++
> > 2 files changed, 13 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index 56d03aa4cd..dae5dd4a11 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -390,6 +390,13 @@ static const struct {
> > "Splitted-Desktop Systems VDPAU backend for VA-API",
> > AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES,
> > },
> > +#if CONFIG_VAAPI_1
> > + {
> > + "New Intel iHD",
> > + "Intel iHD driver for Intel(R) Gen Graphics",
> > + AV_VAAPI_DRIVER_QUIRK_DYNAMIC_SURFACE_POOL,
> > + },
> > +#endif
> > };
> >
> > static int vaapi_device_init(AVHWDeviceContext *hwdev)
> > diff --git a/libavutil/hwcontext_vaapi.h b/libavutil/hwcontext_vaapi.h
> > index 0b2e071cb3..07014fd526 100644
> > --- a/libavutil/hwcontext_vaapi.h
> > +++ b/libavutil/hwcontext_vaapi.h
> > @@ -58,6 +58,12 @@ enum {
> > * and the results of the vaQuerySurfaceAttributes() call will be
> > faked.
> > */
> > AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES = (1 << 3),
> > +
> > + /**
> > + * The driver (and the underlying HW) supports dynamic surface pool.
> > + * The vaCreateContext() call doesn't require a fixed surface-array.
> > + */
> > + AV_VAAPI_DRIVER_QUIRK_DYNAMIC_SURFACE_POOL = (1 << 4),
> > };
> >
> > /**
>
> I do not think a vendor-specific quirk like this is a reasonable answer, but I
> can see that your company is invested in making sure that your current driver
> doesn't hit this problem.
>
> Given that, I give up on arguing for trying to preserve compatibility here.
> Let's just use dynamic pools unconditionally and see if anything breaks.
Thanks, I'll update the patchset to use dynamic pools for all drivers when libva
>= 2.0.
>
> Is there any reason not to drop support for libva < 2.0 at the same time?
> (Making CONFIG_VAAPI_1 always true.) It is of similar age to C17, which we
> are intending to require soon as well.
We are considering to drop the support for libva < 2.0, but we can't be sure
whether user is still using libva < 2.0.
If there isn't any objection about dropping the support for libva < 2.0, We will
use a separate patch to drop the support.
BRs
Haihao
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
