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

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