Re: git: a5e4dc2e4a39 - main - multimedia/vapoursynth: Update to R73 and adopt port
Date: Sun, 21 Jun 2026 07:17:12 UTC
On 2026-06-20 19:55, Vladimir Druzenko wrote:
> 20.06.2026 20:19, Daniel Engberg пишет:
>>
>> On 2026-06-20 17:06, Vladimir Druzenko wrote:
>>> 20.06.2026 14:54, Daniel Engberg пишет:
>>>> On 2026-06-19 22:27, Vladimir Druzenko wrote:
>>>>> After this update build fails:
>>>>> FAILED: [code=1] libavx2.a.p/
>>>>> src_core_kernel_x86_convolution_avx2.cpp.o
>>>>> c++ -Ilibavx2.a.p -I. -I.. -I../include -fvisibility=hidden -flto -
>>>>> fdiagnostics-color=never -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -
>>>>> Winvalid-pch -std=c++17 -DVS_CORE_EXPORTS -DVS_CURRENT_RELEASE=73 -
>>>>> DVS_GRAPH_API '-DVS_PATH_PLUGINDIR="/usr/local/lib/vapoursynth"' -
>>>>> DVS_USE_LATEST_API -DVSSCRIPT_USE_LATEST_API -Wno-ignored-
>>>>> attributes - fno-math-errno -fno-trapping-math -DVS_TARGET_OS_LINUX
>>>>> - DHAVE_SCHED_GETAFFINITY -DHAVE_CPUSET_GETAFFINITY -
>>>>> DVS_TARGET_CPU_X86 - O2 -pipe -march=core2 -fstack-protector-strong
>>>>> -fno-strict-aliasing - fPIC -MD -MQ libavx2.a.p/
>>>>> src_core_kernel_x86_convolution_avx2.cpp.o -MF libavx2.a.p/
>>>>> src_core_kernel_x86_convolution_avx2.cpp.o.d -o libavx2.a.p/
>>>>> src_core_kernel_x86_convolution_avx2.cpp.o -c ../src/ core/kernel/
>>>>> x86/ convolution_avx2.cpp
>>>>
>>>> Addressed in https://cgit.freebsd.org/ports/commit/?
>>>> id=a2fb9923e7014adde1da669b8322e5a8b631fc90
>>>>
>>>> Machine toggles don't help because they reflect on host system not
>>>> target system
>>> First of all, this is not true:
>>> [/usr/ports/multimedia/vapoursynth]$ for C in "" nocona core2 penryn
>>> nehalem westmere sandybridge ivybridge haswell broadwell skylake
>>> skylake-avx512; do CPUTYPE=${C} make -V CPUTYPE -V MACHINE_CPU; echo;
>>> done
>>>
>>> amd64 sse2 sse mmx
>>>
>>> nocona
>>> sse3 amd64 sse2 sse mmx
>>>
>>> core2
>>> ssse3 sse3 amd64 sse2 sse mmx
>>>
>>> penryn
>>> sse41 ssse3 sse3 amd64 sse2 sse mmx
>>>
>>> nehalem
>>> sse42 sse41 ssse3 sse3 amd64 sse2 sse mmx
>>>
>>> westmere
>>> sse42 sse41 ssse3 sse3 amd64 sse2 sse mmx
>>>
>>> sandybridge
>>> avx sse42 sse41 ssse3 sse3 amd64 sse2 sse mmx
>>>
>>> ivybridge
>>> avx sse42 sse41 ssse3 sse3 f16c amd64 sse2 sse mmx
>>>
>>> haswell
>>> avx2 avx sse42 sse41 ssse3 sse3 f16c amd64 sse2 sse mmx
>>>
>>> broadwell
>>> avx2 avx sse42 sse41 ssse3 sse3 f16c amd64 sse2 sse mmx
>>>
>>> skylake
>>> avx2 avx sse42 sse41 ssse3 sse3 f16c amd64 sse2 sse mmx
>>>
>>> skylake-avx512
>>> avx512 avx2 avx sse42 sse41 ssse3 sse3 f16c amd64 sse2 sse mmx
>>>
>>> MACHINE_CPU depends from CPUTYPE and if CPUTYPE is not defined then
>>> MACHINE_CPU have only basic features of the ARCH.
>>> Tested on host with skylake-avx512 Intel Xeon Scalable Bronze 3104
>>> and on Intel Core 2 Quad Q6600.
>>>
>>> Secondly, even if you were right, your fix is more of a joke than a
>>> fix. It doesn't even help with the IvyBridge CPU.
>>
>> Why would it help on ivy bridge if avx2 is the requirement?
>>
>> MACHINE_CPU in it's current form is flawed however it can somewhat
>> determine features based on CPUTYPE but also broken if you have
>> something not defined such as znver5 (Ryzen 9000 series). What I'm not
>> going to do is to maintain a separate list for compatible/non
>> compatible CPUs.
>>
>> Another option would be what we do for OpenEXR but replicating that
>> for each port is less than ideal.
>>
>> Ideally https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272900 would
>> be nice in the end in some form but there are much larger issues to
>> take care of first overall.
>
> Why do you think AVX2 is a requirement? The port builds perfectly well
> without it. Those who want to build with AVX2 can do so themselves. We
> support the base AMD64 architecture even without SSE3 in the ports.
>
> Don't you understand that you broke the port for all CPUs older than
> Haswell?
> With an active review, you simply stole the port and broke it, and now
> you're wasting everyone's time on stupid arguments.
> Essentially, the port is broken now, and instead of arguing with you
> now, I could just commit a fix with "Approved: blanket (fix port)".
>
If you stop with the accusations and spend a moment to get an idea what
you're talking about.
There is no PRs on bz about it, that's the official way of submitting
patches.
https://docs.freebsd.org/en/books/porters-handbook/book/#porting-submitting
Good and common practice is to at least have a placeholder on bz which
you should know by now.
* It compiles on amd64 with a target that supports AVX2 AND have a
corresponding CPUTYPE defined. Ivy Bridge does not support AVX2 hence
failing.
* It compiles on amd64 with a target without AVX2 that doesn't define
CPUTYPE but with (severe) performance penalties. It's a tradeoff, if you
don't compile with CPUTYPE you're likely not looking for getting as much
performance as possible out of your target box. Ports such as math/fftw3
which you'll likely indirectly use with this software also suffers
greatly without CPUTYPE defined on (newer-ish) systems.
* It will fail to compile on targets with CPUTYPE defined and without
AVX2 because we currently don't catch this issue well. Additionally
MACHINE_CPU will also fail on systems not defined such as Ryzen 9000
series aka znver5 or simply revert to minimum ARCH target when CPUTYPE
is undefined. Ideally we'd need something
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272900 that tracks
target feature/instruction set.
I'm not too fond of idea of providing a binary that will be broken on
legacy systems but on the other hand it's meaningless to provide a
binary that's more or less unusable on any system.
We have other ports facing the same issue, such as py-numpy, openexr and
others
https://cgit.freebsd.org/ports/commit/?id=3c11b048c3de3af38dabc809a80dd0fbac51c7ff
https://cgit.freebsd.org/ports/commit/?id=6b50d3885e31662c439e89f43c74617100ce0bd0
Practically it's more or less unusable on a potato as other related
software such as plugins and encoders will either not work at all or be
slow as molasses. You will likely also run into other issues on such
hardware like RAM limitations. Additinally upstream "partially" hard
codes AVX2 support because it makes sense from a performance standpoint.
https://github.com/vapoursynth/vapoursynth/blob/master/meson.build#L14
Best regards,
Daniel