Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
* [FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK Version and check for Runtime-Versions instead
@ 2022-01-03 21:53 Soft Works
  2022-01-12  2:53 ` Xiang, Haihao
  0 siblings, 1 reply; 6+ messages in thread
From: Soft Works @ 2022-01-03 21:53 UTC (permalink / raw)
  To: FFmpeg development discussions and patches

Hi,

this is a follow-up to my recently submitted patch:

“avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)”

That patch only fixes the one important regression from multiple issues which 
have been introduced by recent changes. Those changes have gone in a less
than ideal direction, because they have introduced checks based on the version
of the MSDK which ffmpeg is being compiled against, but they didn’t add 
checks for the runtime libmfx/MSDK versions – and this causes failures, 
sometimes even for functionality which has worked before (=>regressions).

Background

- the compile-sdk version determines which features can be used
  but only when
  - the runtime SDK version supports it
    and
  - the hardware (GPU gen) supports it
- ALL compile-sdk versions can interface with ALL runtime MSDK 
  versions (basically), no matter whether runtime version is newer or
  older
- At least on Windows, some hw is stuck at a certain runtime version,
  e.g.: there are new drivers for Broadwell, but the MSDK runtime
  is always 1.11


Conclusion

Adding checks for the runtime MSDK versions is required wherever a feature
might not be supported by older MSDK runtimes - I think that's an obvious
necessity.


Question

Having both - run-time and compile-time checks all over the code is adding 
a lot of complexity and makes it difficult to maintain and work with.

Hence, I'm wondering whether we couldn't/shouldn't introduce a minimum 
MSDK compile-time version, for example 1.22, or even later?

This would allow simplification of the QSV code in many places where run-time
version checks are actually needed instead.

Over time, there have been better and worse MSDK versions, and there 
should still be enough room for choosing, but I don't think there's any
reason why somebody would still want to compile against some really old 
(e.g. < 1.22) MSDK version. 

Please share your thoughts on this subject..

softworkz


_______________________________________________
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".

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK Version and check for Runtime-Versions instead
  2022-01-03 21:53 [FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK Version and check for Runtime-Versions instead Soft Works
@ 2022-01-12  2:53 ` Xiang, Haihao
  2022-01-12  3:37   ` Soft Works
  0 siblings, 1 reply; 6+ messages in thread
From: Xiang, Haihao @ 2022-01-12  2:53 UTC (permalink / raw)
  To: ffmpeg-devel

On Mon, 2022-01-03 at 21:53 +0000, Soft Works wrote:
> Hi,
> 
> this is a follow-up to my recently submitted patch:
> 
> “avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)”
> 
> That patch only fixes the one important regression from multiple issues which 
> have been introduced by recent changes. Those changes have gone in a less
> than ideal direction, because they have introduced checks based on the version
> of the MSDK which ffmpeg is being compiled against, but they didn’t add 
> checks for the runtime libmfx/MSDK versions – and this causes failures, 
> sometimes even for functionality which has worked before (=>regressions).
> 
> Background
> 
> - the compile-sdk version determines which features can be used
>   but only when
>   - the runtime SDK version supports it
>     and
>   - the hardware (GPU gen) supports it
> - ALL compile-sdk versions can interface with ALL runtime MSDK 
>   versions (basically), no matter whether runtime version is newer or
>   older
> - At least on Windows, some hw is stuck at a certain runtime version,
>   e.g.: there are new drivers for Broadwell, but the MSDK runtime
>   is always 1.11
> 
> 
> Conclusion
> 
> Adding checks for the runtime MSDK versions is required wherever a feature
> might not be supported by older MSDK runtimes - I think that's an obvious
> necessity.
> 
> 
> Question
> 
> Having both - run-time and compile-time checks all over the code is adding 
> a lot of complexity and makes it difficult to maintain and work with.
> 
> Hence, I'm wondering whether we couldn't/shouldn't introduce a minimum 
> MSDK compile-time version, for example 1.22, or even later?
> 
> This would allow simplification of the QSV code in many places where run-time
> version checks are actually needed instead.
> 
> Over time, there have been better and worse MSDK versions, and there 
> should still be enough room for choosing, but I don't think there's any
> reason why somebody would still want to compile against some really old 
> (e.g. < 1.22) MSDK version. 
> 
> Please share your thoughts on this subject..

I agree we may add a requirement for the minimal compiling version in configure,
version 1.28 was released 3 years ago, how about using this version as the
minimal compiling version ? 

BTW you may download the new Windows drivers for Broadwell from 
https://www.intel.com/content/www/us/en/download/18369/intel-graphics-driver-for-windows-15-40.html
 , the runtime version should be 1.20

Thanks
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".

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK Version and check for Runtime-Versions instead
  2022-01-12  2:53 ` Xiang, Haihao
@ 2022-01-12  3:37   ` Soft Works
  2022-05-03 22:13     ` Soft Works
  0 siblings, 1 reply; 6+ messages in thread
From: Soft Works @ 2022-01-12  3:37 UTC (permalink / raw)
  To: FFmpeg development discussions and patches



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Xiang,
> Haihao
> Sent: Wednesday, January 12, 2022 3:53 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK Version and
> check for Runtime-Versions instead
> 
> On Mon, 2022-01-03 at 21:53 +0000, Soft Works wrote:
> > Hi,
> >
> > this is a follow-up to my recently submitted patch:
> >
> > “avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)”
> >
> > That patch only fixes the one important regression from multiple issues
> which
> > have been introduced by recent changes. Those changes have gone in a less
> > than ideal direction, because they have introduced checks based on the
> version
> > of the MSDK which ffmpeg is being compiled against, but they didn’t add
> > checks for the runtime libmfx/MSDK versions – and this causes failures,
> > sometimes even for functionality which has worked before (=>regressions).
> >
> > Background
> >
> > - the compile-sdk version determines which features can be used
> >   but only when
> >   - the runtime SDK version supports it
> >     and
> >   - the hardware (GPU gen) supports it
> > - ALL compile-sdk versions can interface with ALL runtime MSDK
> >   versions (basically), no matter whether runtime version is newer or
> >   older
> > - At least on Windows, some hw is stuck at a certain runtime version,
> >   e.g.: there are new drivers for Broadwell, but the MSDK runtime
> >   is always 1.11
> >
> >
> > Conclusion
> >
> > Adding checks for the runtime MSDK versions is required wherever a feature
> > might not be supported by older MSDK runtimes - I think that's an obvious
> > necessity.
> >
> >
> > Question
> >
> > Having both - run-time and compile-time checks all over the code is adding
> > a lot of complexity and makes it difficult to maintain and work with.
> >
> > Hence, I'm wondering whether we couldn't/shouldn't introduce a minimum
> > MSDK compile-time version, for example 1.22, or even later?
> >
> > This would allow simplification of the QSV code in many places where run-
> time
> > version checks are actually needed instead.
> >
> > Over time, there have been better and worse MSDK versions, and there
> > should still be enough room for choosing, but I don't think there's any
> > reason why somebody would still want to compile against some really old
> > (e.g. < 1.22) MSDK version.
> >
> > Please share your thoughts on this subject..
> 
> I agree we may add a requirement for the minimal compiling version in
> configure,
> version 1.28 was released 3 years ago, how about using this version as the
> minimal compiling version ?

I'm fine with 1.28!


> BTW you may download the new Windows drivers for Broadwell from
> https://www.intel.com/content/www/us/en/download/18369/intel-graphics-driver-
> for-windows-15-40.html
>  , the runtime version should be 1.20

My mistake, I mixed the code names up. It was about a 3rd gen CPU. Those 
are stuck at 1.11. 4th and 5th gen are stuck at 1.20 and the others get the 
latest MSDK runtime.

It's like I had described in 2020 here: https://github.com/softworkz/ffmpeg_dx11/issues/1

Thanks,
softworkz


_______________________________________________
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".

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK Version and check for Runtime-Versions instead
  2022-01-12  3:37   ` Soft Works
@ 2022-05-03 22:13     ` Soft Works
  2022-05-22 12:24       ` Xiang, Haihao
  0 siblings, 1 reply; 6+ messages in thread
From: Soft Works @ 2022-05-03 22:13 UTC (permalink / raw)
  To: FFmpeg development discussions and patches



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Soft
> Works
> Sent: Wednesday, January 12, 2022 4:37 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK
> Version and check for Runtime-Versions instead

[..]

> > > Question
> > >
> > > Having both - run-time and compile-time checks all over the code
> is adding
> > > a lot of complexity and makes it difficult to maintain and work
> with.
> > >
> > > Hence, I'm wondering whether we couldn't/shouldn't introduce a
> minimum
> > > MSDK compile-time version, for example 1.22, or even later?
> > >
> > > This would allow simplification of the QSV code in many places
> where run-
> > time
> > > version checks are actually needed instead.
> > >
> > > Over time, there have been better and worse MSDK versions, and
> there
> > > should still be enough room for choosing, but I don't think
> there's any
> > > reason why somebody would still want to compile against some
> really old
> > > (e.g. < 1.22) MSDK version.
> > >
> > > Please share your thoughts on this subject..
> >
> > I agree we may add a requirement for the minimal compiling version
> in
> > configure,
> > version 1.28 was released 3 years ago, how about using this version
> as the
> > minimal compiling version ?
> 
> I'm fine with 1.28!


Are there any objections towards setting 1.28 as a minimum requirement 
for the MSDK (QSV) compile-time version?

sw



_______________________________________________
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".

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK Version and check for Runtime-Versions instead
  2022-05-03 22:13     ` Soft Works
@ 2022-05-22 12:24       ` Xiang, Haihao
  2022-05-22 16:28         ` Soft Works
  0 siblings, 1 reply; 6+ messages in thread
From: Xiang, Haihao @ 2022-05-22 12:24 UTC (permalink / raw)
  To: ffmpeg-devel


> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Soft
> > Works
> > Sent: Wednesday, January 12, 2022 4:37 AM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK
> > Version and check for Runtime-Versions instead
> 
> [..]
> 
> > > > Question
> > > > 
> > > > Having both - run-time and compile-time checks all over the code
> > 
> > is adding
> > > > a lot of complexity and makes it difficult to maintain and work
> > 
> > with.
> > > > 
> > > > Hence, I'm wondering whether we couldn't/shouldn't introduce a
> > 
> > minimum
> > > > MSDK compile-time version, for example 1.22, or even later?
> > > > 
> > > > This would allow simplification of the QSV code in many places
> > 
> > where run-
> > > time
> > > > version checks are actually needed instead.
> > > > 
> > > > Over time, there have been better and worse MSDK versions, and
> > 
> > there
> > > > should still be enough room for choosing, but I don't think
> > 
> > there's any
> > > > reason why somebody would still want to compile against some
> > 
> > really old
> > > > (e.g. < 1.22) MSDK version.
> > > > 
> > > > Please share your thoughts on this subject..
> > > 
> > > I agree we may add a requirement for the minimal compiling version
> > 
> > in
> > > configure,
> > > version 1.28 was released 3 years ago, how about using this version
> > 
> > as the
> > > minimal compiling version ?
> > 
> > I'm fine with 1.28!
> 
> 
> Are there any objections towards setting 1.28 as a minimum requirement 
> for the MSDK (QSV) compile-time version?
> 

I submitted https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296699.html,could you take a look when you have time ? 

Thanks
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".

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK Version and check for Runtime-Versions instead
  2022-05-22 12:24       ` Xiang, Haihao
@ 2022-05-22 16:28         ` Soft Works
  0 siblings, 0 replies; 6+ messages in thread
From: Soft Works @ 2022-05-22 16:28 UTC (permalink / raw)
  To: FFmpeg development discussions and patches



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Xiang,
> Haihao
> Sent: Sunday, May 22, 2022 2:25 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK Version
> and check for Runtime-Versions instead
> 
> 
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Soft
> > > Works
> > > Sent: Wednesday, January 12, 2022 4:37 AM
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK
> > > Version and check for Runtime-Versions instead
> >
> > [..]
> >
> > > > > Question
> > > > >
> > > > > Having both - run-time and compile-time checks all over the code
> > >
> > > is adding
> > > > > a lot of complexity and makes it difficult to maintain and work
> > >
> > > with.
> > > > >
> > > > > Hence, I'm wondering whether we couldn't/shouldn't introduce a
> > >
> > > minimum
> > > > > MSDK compile-time version, for example 1.22, or even later?
> > > > >
> > > > > This would allow simplification of the QSV code in many places
> > >
> > > where run-
> > > > time
> > > > > version checks are actually needed instead.
> > > > >
> > > > > Over time, there have been better and worse MSDK versions, and
> > >
> > > there
> > > > > should still be enough room for choosing, but I don't think
> > >
> > > there's any
> > > > > reason why somebody would still want to compile against some
> > >
> > > really old
> > > > > (e.g. < 1.22) MSDK version.
> > > > >
> > > > > Please share your thoughts on this subject..
> > > >
> > > > I agree we may add a requirement for the minimal compiling version
> > >
> > > in
> > > > configure,
> > > > version 1.28 was released 3 years ago, how about using this version
> > >
> > > as the
> > > > minimal compiling version ?
> > >
> > > I'm fine with 1.28!
> >
> >
> > Are there any objections towards setting 1.28 as a minimum requirement
> > for the MSDK (QSV) compile-time version?
> >
> 
> I submitted https://ffmpeg.org/pipermail/ffmpeg-devel/2022-
> May/296699.html,could you take a look when you have time ?

Hi Haihao,

thanks a lot for taking care of this, I just couldn't find the time
since I had made the suggestion.

I got it merged and going over it now.

sw



_______________________________________________
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".

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-05-22 16:28 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-03 21:53 [FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK Version and check for Runtime-Versions instead Soft Works
2022-01-12  2:53 ` Xiang, Haihao
2022-01-12  3:37   ` Soft Works
2022-05-03 22:13     ` Soft Works
2022-05-22 12:24       ` Xiang, Haihao
2022-05-22 16:28         ` Soft Works

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