From: Soft Works <softworkz@hotmail.com> 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 Date: Wed, 12 Jan 2022 03:37:15 +0000 Message-ID: <DM8P223MB0365C08FC310774E59FB819CBA529@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw) In-Reply-To: <913a95be74c1c570f0d36e5060fc22ebc8206fd1.camel@intel.com> > -----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".
next prev parent reply other threads:[~2022-01-12 3:37 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-03 21:53 Soft Works 2022-01-12 2:53 ` Xiang, Haihao 2022-01-12 3:37 ` Soft Works [this message] 2022-05-03 22:13 ` Soft Works 2022-05-22 12:24 ` Xiang, Haihao 2022-05-22 16:28 ` Soft Works
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=DM8P223MB0365C08FC310774E59FB819CBA529@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM \ --to=softworkz@hotmail.com \ --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