[FFmpeg-devel] configure: disable vulkan if min version insufficient

相关文章推荐

有腹肌的红烧肉 · vuejs/vue-router: The ...· 6 月前 ·

闷骚的四季豆 · 坚持胸怀天下促进人类进步- 求是网· 6 月前 ·

失望的鸵鸟 · ColorOS 14 ...· 1 年前 ·

侠义非凡的大象 · 雪铁龙世嘉变速箱锁3档_雪铁龙_世嘉_汽车大师· 1 年前 ·

急躁的番茄 · 大熊猫的便便竟然是香的？不仅好闻还能用来擦嘴 ...· 1 年前 ·

Received-SPF: pass (google.com: domain of [email protected]
 designates 79.124.17.100 as permitted sender) client-ip=79.124.17.100;
From: Tristan Matthews <[email protected]>
To: [email protected]
Date: Fri, 29 Sep 2023 09:52:54 -0400
Message-Id: <[email protected]>
MIME-Version: 1.0
Subject: [FFmpeg-devel] [PATCH] configure: disable vulkan if min version
 insufficient
Precedence: list
Reply-To: FFmpeg development discussions and patches <[email protected]>
Cc: Tristan Matthews <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: [email protected]
Sender: "ffmpeg-devel" <[email protected]>

On 29.09.2023 15:52, Tristan Matthews wrote: > Fixes: https://trac.ffmpeg.org/ticket/10596 > configure | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > diff --git a/configure b/configure > index 20db1801ed..50ba6f772f 100755 > --- a/configure > +++ b/configure > @@ -7154,7 +7154,8 @@ enabled crystalhd && check_lib crystalhd "stdint.h libcrystalhd/libcrystalhd_if. > if enabled vulkan; then > check_pkg_config_header_only vulkan "vulkan >= 1.3.255" "vulkan/vulkan.h" "defined VK_VERSION_1_3" || > - check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" > + check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" || > + warn "Disabling vulkan" && disable vulkan Doesn't that just always disable vulkan if any of the previous checks succeed? The logic looks weird to me. Also, shouldn't all of those check_* calls disable vulkan already? That's what the first argument is for. On Fri, Sep 29, 2023 at 1:37 PM Timo Rothenpieler <[email protected]> wrote: > On 29.09.2023 15:52, Tristan Matthews wrote: > > Fixes: https://trac.ffmpeg.org/ticket/10596 > > configure | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/configure b/configure > > index 20db1801ed..50ba6f772f 100755 > > --- a/configure > > +++ b/configure > > @@ -7154,7 +7154,8 @@ enabled crystalhd && check_lib crystalhd "stdint.h libcrystalhd/libcrystalhd_if. > > if enabled vulkan; then > > check_pkg_config_header_only vulkan "vulkan >= 1.3.255" "vulkan/vulkan.h" "defined VK_VERSION_1_3" || > > - check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" > > + check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" || > > + warn "Disabling vulkan" && disable vulkan > Doesn't that just always disable vulkan if any of the previous checks > succeed? The logic looks weird to me. No, it will only disable vulkan if all the previous checks fail as this conditional shortcircuits (so to get to here it would have to be false || false || false || false || false || warn "Disable vulkan" && disable vulkan). If I hack the version number to match mine (changing it to 1.3.239), vulkan won't be disabled (that's why I added the warning message) and you'll hit the build breakage I and others are hitting currently. > Also, shouldn't all of those check_* calls disable vulkan already? > That's what the first argument is for. They don't, so my first thought was that since this is the only place where check_pkg_config_header_only is called, it seemed likely that there was a bug in that function. However, I couldn't spot anything obviously broken in it and it is returning the correct value (hence this patch behaving as expected). Best, Tristan > _______________________________________________ > ffmpeg-devel mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". On Fri, Sep 29, 2023 at 3:55 PM Tristan Matthews <[email protected]> wrote: > Fixes: https://trac.ffmpeg.org/ticket/10596 > configure | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > diff --git a/configure b/configure > index 20db1801ed..50ba6f772f 100755 > --- a/configure > +++ b/configure > @@ -7154,7 +7154,8 @@ enabled crystalhd && check_lib crystalhd "stdint.h libcrystalhd/libcrystalhd_if. > if enabled vulkan; then > check_pkg_config_header_only vulkan "vulkan >= 1.3.255" "vulkan/vulkan.h" "defined VK_VERSION_1_3" || > - check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" > + check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" || > + warn "Disabling vulkan" && disable vulkan This change doesn't seem right. If a feature is explicitly requested, we generally fail the build and don't just disable the feature (afterall the user wanted it to be on). If the feature is not explicitly requested, then it should not print a message. - Hendrik On Fri, Sep 29, 2023 at 2:32 PM Hendrik Leppkes <[email protected]> wrote: > On Fri, Sep 29, 2023 at 3:55 PM Tristan Matthews <[email protected]> wrote: > > Fixes: https://trac.ffmpeg.org/ticket/10596 > > configure | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/configure b/configure > > index 20db1801ed..50ba6f772f 100755 > > --- a/configure > > +++ b/configure > > @@ -7154,7 +7154,8 @@ enabled crystalhd && check_lib crystalhd "stdint.h libcrystalhd/libcrystalhd_if. > > if enabled vulkan; then > > check_pkg_config_header_only vulkan "vulkan >= 1.3.255" "vulkan/vulkan.h" "defined VK_VERSION_1_3" || > > - check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" > > + check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" || > > + warn "Disabling vulkan" && disable vulkan > This change doesn't seem right. If a feature is explicitly requested, > we generally fail the build and don't just disable the feature > (afterall the user wanted it to be on). That is the case here, with or without this patch, on my system --enable-vulkan will fail as expected on: > ERROR: vulkan requested but not found The bug I'm trying to address is the autodetect case. I'm happy to drop the warning, I just wanted it to be obvious what was happening (but one could infer it from the list of modules that will be built). > If the feature is not > explicitly requested, then it should not print a message. On 29.09.2023 20:10, Tristan Matthews wrote: > On Fri, Sep 29, 2023 at 1:37 PM Timo Rothenpieler <[email protected]> wrote: >> On 29.09.2023 15:52, Tristan Matthews wrote: >>> Fixes: https://trac.ffmpeg.org/ticket/10596 >>> configure | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> diff --git a/configure b/configure >>> index 20db1801ed..50ba6f772f 100755 >>> --- a/configure >>> +++ b/configure >>> @@ -7154,7 +7154,8 @@ enabled crystalhd && check_lib crystalhd "stdint.h libcrystalhd/libcrystalhd_if. >>> if enabled vulkan; then >>> check_pkg_config_header_only vulkan "vulkan >= 1.3.255" "vulkan/vulkan.h" "defined VK_VERSION_1_3" || >>> - check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" >>> + check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" || >>> + warn "Disabling vulkan" && disable vulkan >> Doesn't that just always disable vulkan if any of the previous checks >> succeed? The logic looks weird to me. > No, it will only disable vulkan if all the previous checks fail as > this conditional shortcircuits (so to get to here it would have to be > false || false || false || false || false || warn "Disable vulkan" && > disable vulkan). If I hack the version number to match mine (changing > it to 1.3.239), vulkan won't be disabled (that's why I added the > warning message) and you'll hit the build breakage I and others are > hitting currently. My shell disagrees: $ function warn() { echo $1; } $ true || false || warn "Disabling vulkan" && echo DISABLED DISABLED $ false || true || warn "Disabling vulkan" && echo DISABLED DISABLED $ false || false || warn "Disabling vulkan" && echo DISABLED Disabling vulkan DISABLED $ true || true || warn "Disabling vulkan" && echo DISABLED DISABLED No matter the results of the checks, this will always disable Vulkan, since the chain before it will always have a positive outcome, so && continues. On Fri, Sep 29, 2023 at 3:26 PM Timo Rothenpieler <[email protected]> wrote: > On 29.09.2023 20:10, Tristan Matthews wrote: > > On Fri, Sep 29, 2023 at 1:37 PM Timo Rothenpieler <[email protected]> wrote: > >> On 29.09.2023 15:52, Tristan Matthews wrote: > >>> Fixes: https://trac.ffmpeg.org/ticket/10596 > >>> configure | 3 ++- > >>> 1 file changed, 2 insertions(+), 1 deletion(-) > >>> diff --git a/configure b/configure > >>> index 20db1801ed..50ba6f772f 100755 > >>> --- a/configure > >>> +++ b/configure > >>> @@ -7154,7 +7154,8 @@ enabled crystalhd && check_lib crystalhd "stdint.h libcrystalhd/libcrystalhd_if. > >>> if enabled vulkan; then > >>> check_pkg_config_header_only vulkan "vulkan >= 1.3.255" "vulkan/vulkan.h" "defined VK_VERSION_1_3" || > >>> - check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" > >>> + check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" || > >>> + warn "Disabling vulkan" && disable vulkan > >> Doesn't that just always disable vulkan if any of the previous checks > >> succeed? The logic looks weird to me. > > No, it will only disable vulkan if all the previous checks fail as > > this conditional shortcircuits (so to get to here it would have to be > > false || false || false || false || false || warn "Disable vulkan" && > > disable vulkan). If I hack the version number to match mine (changing > > it to 1.3.239), vulkan won't be disabled (that's why I added the > > warning message) and you'll hit the build breakage I and others are > > hitting currently. > My shell disagrees: > $ function warn() { echo $1; } > $ true || false || warn "Disabling vulkan" && echo DISABLED > DISABLED > $ false || true || warn "Disabling vulkan" && echo DISABLED > DISABLED > $ false || false || warn "Disabling vulkan" && echo DISABLED > Disabling vulkan > DISABLED > $ true || true || warn "Disabling vulkan" && echo DISABLED > DISABLED > No matter the results of the checks, this will always disable Vulkan, > since the chain before it will always have a positive outcome, so && > continues. Oh I see, I should have parens around the last bit, e.g.: false || true || (warn "Disabling vulkan" && echo DISABLED) but as Hendrik mentioned, the warning can be dropped in which case this would become: check_pkg_config_header_only vulkan ... || check_cpp_condition || disable vulkan As mentioned earlier in the thread if someone has a better idea of how to avoid explicitly calling disable vulkan like this (i.e. why isn't this already working) that would of course be preferable. Best, --- a/configure +++ b/configure @@ -7154,7 +7154,8 @@ enabled crystalhd && check_lib crystalhd "stdint.h libcrystalhd/libcrystalhd_if. if enabled vulkan; then check_pkg_config_header_only vulkan "vulkan >= 1.3.255" "vulkan/vulkan.h" "defined VK_VERSION_1_3" || - check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" + check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)" || + warn "Disabling vulkan" && disable vulkan if enabled x86; then