Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: "Xiang, Haihao" <haihao.xiang-at-intel.com@ffmpeg.org>
To: "ffmpeg-devel@ffmpeg.org" <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavu/hwcontext_vaapi: Add a new quirk
Date: Sun, 7 Apr 2024 05:12:16 +0000
Message-ID: <7ae694aebbcf62acedf801752838f6aa8ae7a872.camel@intel.com> (raw)
In-Reply-To: <1e0af962-33b5-4226-8344-8cd39d77dc9b@jkqxz.net>

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.xiang@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.xiang@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-request@ffmpeg.org with subject "unsubscribe".

      reply	other threads:[~2024-04-07  5:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28  2:17 Xiang, Haihao
2024-03-28  2:17 ` [FFmpeg-devel] [PATCH 2/3] lavc/vaapi_decode: Use dynamic frame pool if possible Xiang, Haihao
2024-03-28  2:17 ` [FFmpeg-devel] [PATCH 3/3] lavfi/vaapi_vpp: Use dynamic frame pool in outlink " Xiang, Haihao
2024-04-03  1:40 ` [FFmpeg-devel] [PATCH 1/3] lavu/hwcontext_vaapi: Add a new quirk Xiang, Haihao
2024-04-03 19:21 ` Mark Thompson
2024-04-07  5:12   ` Xiang, Haihao [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7ae694aebbcf62acedf801752838f6aa8ae7a872.camel@intel.com \
    --to=haihao.xiang-at-intel.com@ffmpeg.org \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git