Summary: | Failure to build with XSIMD support | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | Timo Gurr <timo.gurr> |
Component: | General | Assignee: | amyspark <amy> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | halla, tomtomtomreportingin |
Priority: | NOR | ||
Version First Reported In: | 5.1.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/graphics/krita/commit/9add01e5a5818be5e0a6d4d787adb8645b09d049 | Version Fixed In: | |
Sentry Crash Report: | |||
Attachments: |
krita-5.1.0_build.log
krita-5.1.0-xsimd.patch |
Description
Timo Gurr
2022-08-18 15:01:18 UTC
Created attachment 151407 [details]
krita-5.1.0_build.log
The check that's failing means that the size of the `unsigned int` type in your system is *not* 32 bits, which renders those functions unusable. Can you check what your compiler returns for the size of `unsigned int`? Alternatively, can you replace the definitions in libs\pigment\compositeops\KoStreamedMath.h as follows, and try building Krita again? Replace "int" and "unsigned int" for "int32_t" and "uint32_t" respectively, in`struct PixelWrapper<quint16, ...>` and `struct PixelWrapper<float, ...>`. I will at least say that I've also had problems building recent versions of Krita on my Debian sid system. The error I would get at around the 7% mark would be "/usr/bin/ld: cannot find -lxtl: No such file or directory", but it would stop at the same file. Passing the flag that Timo noted seems to workaround the issue, so it's likely also xsimd related. (In reply to amyspark from comment #2) > Can you check what your compiler returns for the size of `unsigned int`? Sorry I've no idea how to do that. > Alternatively, can you replace the definitions in > libs\pigment\compositeops\KoStreamedMath.h as follows, and try building > Krita again? Replace "int" and "unsigned int" for "int32_t" and "uint32_t" > respectively, in`struct PixelWrapper<quint16, ...>` and `struct > PixelWrapper<float, ...>`. I'm attaching the patch I'm using as krita-5.1.0-xsimd.patch, maybe I did something wrong, with it applied I get the following error: /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/compositeops/KoRgbaInterleavers.h:176:37: error: no matching function for call to 'KoRgbaInterleavers<16>::deinterleave<false>(const void*&, xsimd::batch<unsigned int, xsimd::avx>&, xsimd::batch<unsigned int, xsimd::avx>&, xsimd::avx)' 176 | return deinterleave<aligned>(src, a, b, A{}); | ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/compositeops/KoRgbaInterleavers.h:131:24: note: candidate: 'template<bool aligned, class T, class A, typename std::enable_if<(std::is_integral<_Size>::value && (sizeof (T) == 4)), int>::type <anonymous>, typename std::enable_if<(xsimd::batch<T, A>::size == 4), int>::type <anonymous> > static void KoRgbaInterleavers<16>::deinterleave(const void*, xsimd::batch<T, A>&, xsimd::batch<T, A>&, xsimd::kernel::requires_arch<xsimd::generic>)' 131 | static inline void deinterleave(const void *src, batch<T, A> &dst1, batch<T, A> &dst2, kernel::requires_arch<generic>) | ^~~~~~~~~~~~ /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/compositeops/KoRgbaInterleavers.h:131:24: note: template argument deduction/substitution failed: /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/compositeops/KoRgbaInterleavers.h:130:120: error: no type named 'type' in 'struct std::enable_if<false, int>' 130 | template<bool aligned, typename T, typename A, enable_sized_integral_t<T, 4> = 0, enable_sized_vector_t<T, A, 4> = 0> | ^ /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/compositeops/KoRgbaInterleavers.h:146:24: note: candidate: 'template<bool aligned, class T, class A, typename std::enable_if<(sizeof (T) == 4), int>::type <anonymous> > static void KoRgbaInterleavers<16>::deinterleave(const void*, xsimd::batch<T, A>&, xsimd::batch<T, A>&, xsimd::kernel::requires_arch<xsimd::avx2>)' 146 | static inline void deinterleave(const void *src, batch<T, A> &a, batch<T, A> &b, kernel::requires_arch<avx2>) | ^~~~~~~~~~~~ /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/compositeops/KoRgbaInterleavers.h:146:24: note: template argument deduction/substitution failed: /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/compositeops/KoRgbaInterleavers.h:176:37: note: cannot convert 'xsimd::avx()' (type 'xsimd::avx') to type 'xsimd::kernel::requires_arch<xsimd::avx2>' {aka 'const xsimd::avx2&'} 176 | return deinterleave<aligned>(src, a, b, A{}); | ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/compositeops/KoRgbaInterleavers.h:174:24: note: candidate: 'template<class T, class A, bool aligned> static void KoRgbaInterleavers<16>::deinterleave(const void*, xsimd::batch<T, A>&, xsimd::batch<T, A>&)' 174 | static inline void deinterleave(const void *src, batch<T, A> &a, batch<T, A> &b) | ^~~~~~~~~~~~ /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/compositeops/KoRgbaInterleavers.h:174:24: note: template argument deduction/substitution failed: /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/compositeops/KoRgbaInterleavers.h:176:37: error: type/value mismatch at argument 1 in template parameter list for 'template<class T, class A, bool aligned> static void KoRgbaInterleavers<16>::deinterleave(const void*, xsimd::batch<T, A>&, xsimd::batch<T, A>&)' 176 | return deinterleave<aligned>(src, a, b, A{}); | ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/compositeops/KoRgbaInterleavers.h:176:37: note: expected a type, got 'false' In regards to what tomtomtomreportingin@gmail.com just posted I want to note that we currently compile our xsimd package with xtl support disabled by passing -DENABLE_XTL_COMPLEX:BOOL=FALSE since we didn't package https://github.com/xtensor-stack/xtl yet. Created attachment 151414 [details]
krita-5.1.0-xsimd.patch
(In reply to tomtomtomreportingin from comment #3) > I will at least say that I've also had problems building recent versions of > Krita on my Debian sid system. The error I would get at around the 7% mark > would be "/usr/bin/ld: cannot find -lxtl: No such file or directory", but it > would stop at the same file. > > Passing the flag that Timo noted seems to workaround the issue, so it's > likely also xsimd related. We don't use xtensor-stack's xtl since we have no need for complex number maths (yet). So that would be best reported to your distribution. (In reply to Timo Gurr from comment #4) > (In reply to amyspark from comment #2) > > Can you check what your compiler returns for the size of `unsigned int`? > Sorry I've no idea how to do that. > > > Alternatively, can you replace the definitions in > > libs\pigment\compositeops\KoStreamedMath.h as follows, and try building > > Krita again? Replace "int" and "unsigned int" for "int32_t" and "uint32_t" > > respectively, in`struct PixelWrapper<quint16, ...>` and `struct > > PixelWrapper<float, ...>`. > > I'm attaching the patch I'm using as krita-5.1.0-xsimd.patch, maybe I did > something wrong, with it applied I get the following error: > > /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/ > compositeops/KoRgbaInterleavers.h:176:37: error: no matching function for > call to 'KoRgbaInterleavers<16>::deinterleave<false>(const void*&, > xsimd::batch<unsigned int, xsimd::avx>&, xsimd::batch<unsigned int, > xsimd::avx>&, xsimd::avx)' > 176 | return deinterleave<aligned>(src, a, b, A{}); > | ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ > /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/ > compositeops/KoRgbaInterleavers.h:131:24: note: candidate: 'template<bool > aligned, class T, class A, typename > std::enable_if<(std::is_integral<_Size>::value && (sizeof (T) == 4)), > int>::type <anonymous>, typename std::enable_if<(xsimd::batch<T, A>::size == > 4), int>::type <anonymous> > static void > KoRgbaInterleavers<16>::deinterleave(const void*, xsimd::batch<T, A>&, > xsimd::batch<T, A>&, xsimd::kernel::requires_arch<xsimd::generic>)' > 131 | static inline void deinterleave(const void *src, batch<T, A> > &dst1, batch<T, A> &dst2, kernel::requires_arch<generic>) > | ^~~~~~~~~~~~ > /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/ > compositeops/KoRgbaInterleavers.h:131:24: note: template argument > deduction/substitution failed: > /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/ > compositeops/KoRgbaInterleavers.h:130:120: error: no type named 'type' in > 'struct std::enable_if<false, int>' > 130 | template<bool aligned, typename T, typename A, > enable_sized_integral_t<T, 4> = 0, enable_sized_vector_t<T, A, 4> = 0> > | > ^ > /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/ > compositeops/KoRgbaInterleavers.h:146:24: note: candidate: 'template<bool > aligned, class T, class A, typename std::enable_if<(sizeof (T) == 4), > int>::type <anonymous> > static void > KoRgbaInterleavers<16>::deinterleave(const void*, xsimd::batch<T, A>&, > xsimd::batch<T, A>&, xsimd::kernel::requires_arch<xsimd::avx2>)' > 146 | static inline void deinterleave(const void *src, batch<T, A> &a, > batch<T, A> &b, kernel::requires_arch<avx2>) > | ^~~~~~~~~~~~ > /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/ > compositeops/KoRgbaInterleavers.h:146:24: note: template argument > deduction/substitution failed: > /var/tmp/paludis/build/media-gfx-krita-5.1.0/work/krita-5.1.0/libs/pigment/ > compositeops/KoRgbaInterleavers.h:176:37: note: cannot convert > 'xsimd::avx()' (type 'xsimd::avx') to type > 'xsimd::kernel::requires_arch<xsimd::avx2>' {aka 'const xsimd::avx2&'} > 176 | return deinterleave<aligned>(src, a, b, A{}); > | ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ I'm afraid your compiler is definitely reporting the wrong size for 32-bit unsigned integers (not 4 bytes), hence the generic version won't be usable. There's nothing we can do on our end, you'll have to upgrade GCC or build Krita without SIMD acceleration. For this reason, marking as NOT A BUG. (In reply to amyspark from comment #7) > I'm afraid your compiler is definitely reporting the wrong size for 32-bit > unsigned integers (not 4 bytes), hence the generic version won't be usable. > There's nothing we can do on our end, you'll have to upgrade GCC or build > Krita without SIMD acceleration. > > For this reason, marking as NOT A BUG. I haven't come across any issues with other packages and since we're a source-based distribution and compile everything such fundamental issues should become directly obvious. Also our GCC version is pretty recent: # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/x86_64-pc-linux-gnu/libexec/gcc/x86_64-pc-linux-gnu/11.3.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/paludis/build/sys-devel-gcc-11.3.0/work/gcc-11.3.0/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --prefix=/usr/x86_64-pc-linux-gnu --datarootdir=/usr/share --localstatedir=/var --sysconfdir=/etc --disable-dependency-tracking --enable-fast-install --enable-serial-configure --disable-bootstrap --disable-decimal-float --disable-install-libiberty --disable-libada --disable-libatomic --disable-libcilkrts --disable-libffi --disable-libgfortran --disable-libgo --disable-libgomp --disable-libitm --disable-libobjc --disable-liboffloadmic --disable-libquadmath --disable-libsanitizer --disable-libssp --disable-libstdcxx --disable-libstdc++-v3 --disable-libvtv --disable-vtable-verify --disable-multilib --disable-nls --disable-shared --enable-lto --enable-plugin --enable-plugins --enable-threads --enable-languages=c,c++,fortran,objc,obj-c++ --with-sysroot= --with-gxx-include-dir=/usr/x86_64-pc-linux-gnu/include/c++/11.3.0 --with-isl --with-lib-path=/usr/x86_64-pc-linux-gnu/lib --with-as=/usr/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/bin/as.binutils --with-ld=/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld --with-system-zlib --with-glibc-version=2.11 --enable-linker-build-id --with-multilib-list= --disable-libhsail-rt --disable-libphobos --enable-default-pie --enable-analyzer --without-zstd --program-transform='s,$,-11,' --enable-cet Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.3.0 (GCC) and I've also just tried it on another system which was just recently upgraded to GCC 12 and successfully recompiled every single package installed and can reproduce the issue there as well. # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/x86_64-pc-linux-gnu/libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/paludis/build/sys-devel-gcc-12.1.0/work/gcc-12.1.0/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --prefix=/usr/x86_64-pc-linux-gnu --datarootdir=/usr/share --localstatedir=/var --sysconfdir=/etc --disable-dependency-tracking --enable-fast-install --enable-serial-configure --disable-bootstrap --disable-decimal-float --disable-install-libiberty --disable-libada --disable-libatomic --disable-libcilkrts --disable-libffi --disable-libgfortran --disable-libgo --disable-libgomp --disable-libitm --disable-libobjc --disable-liboffloadmic --disable-libquadmath --disable-libsanitizer --disable-libssp --disable-libstdcxx --disable-libstdc++-v3 --disable-libvtv --disable-vtable-verify --disable-multilib --disable-nls --disable-shared --enable-lto --enable-plugin --enable-plugins --enable-threads --enable-languages=c,c++,fortran,objc,obj-c++ --with-sysroot= --with-gxx-include-dir=/usr/x86_64-pc-linux-gnu/include/c++/12.1.0 --without-isl --with-lib-path=/usr/x86_64-pc-linux-gnu/lib --with-as=/usr/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/bin/as.binutils --with-ld=/usr/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu-ld --with-system-zlib --with-glibc-version=2.11 --enable-linker-build-id --with-multilib-list= --disable-pgo-build --disable-werror --disable-libphobos --enable-default-pie --enable-analyzer --without-zstd --program-transform='s,$,-12,' --enable-cet Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.1.0 (GCC) Both systems are on glibc 2.36 and binutils 2.39 if that might be of any relevance. (In reply to Timo Gurr from comment #8) > I haven't come across any issues with other packages and since we're a > source-based distribution and compile everything such fundamental issues > should become directly obvious. > > Also our GCC version is pretty recent: The RGBA interleavers code that's causing the error checks for 256-bit wide vectors (AVX) of 32-bit integers. Your version of GCC is reporting `unsigned int` to not be 32-bit in size. I do not know what your distribution is doing, but the code is not designed for that circumstance. FTR, I compile the code with Clang 14.0.6, GCC 12.1 (MSYS flavours CLANG64 and UCRT64), and MSVC 17.4 Preview 1. All of them work correctly. (In reply to amyspark from comment #9) > (In reply to Timo Gurr from comment #8) > > I haven't come across any issues with other packages and since we're a > > source-based distribution and compile everything such fundamental issues > > should become directly obvious. > > > > Also our GCC version is pretty recent: > > The RGBA interleavers code that's causing the error checks for 256-bit wide > vectors (AVX) of 32-bit integers. Your version of GCC is reporting `unsigned > int` to not be 32-bit in size. I do not know what your distribution is > doing, but the code is not designed for that circumstance. > > FTR, I compile the code with Clang 14.0.6, GCC 12.1 (MSYS flavours CLANG64 > and UCRT64), and MSVC 17.4 Preview 1. All of them work correctly. After further investigation and finding the actual problem I'd say this is clearly an issue on your side regarding the CMake magic you've implemented doing the wrong thing since if I compile with -march=x86-64 krita builds just fine with vectorization/xsimd enabled, but it fails when trying to build with -march=native on the very same machine with nothing else changed. That shouldn't be the case and I don't consider this an issue with our compiler. Probably you should be able to reproduce this when trying to compile with -march=native as well, not sure what the CMake magic does in regards to different hardware/processor features though and if that may also play a role here. For reference, working: CHOST="x86_64-pc-linux-gnu" x86_64_pc_linux_gnu_CFLAGS="-march=x86-64 -O2 -pipe" x86_64_pc_linux_gnu_CXXFLAGS="-march=x86-64 -O2 -pipe" Failing: CHOST="x86_64-pc-linux-gnu" x86_64_pc_linux_gnu_CFLAGS="-march=native -O2 -pipe" x86_64_pc_linux_gnu_CXXFLAGS="-march=native -O2 -pipe" /proc/cpuinfo of CPUs tested on: vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz stepping : 3 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities vendor_id : GenuineIntel cpu family : 6 model : 85 model name : Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz stepping : 4 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xsaves arat pku ospke md_clear flush_l1d arch_capabilities (In reply to Timo Gurr from comment #10) > (In reply to amyspark from comment #9) > > (In reply to Timo Gurr from comment #8) > > > I haven't come across any issues with other packages and since we're a > > > source-based distribution and compile everything such fundamental issues > > > should become directly obvious. > > > > > > Also our GCC version is pretty recent: > > > > The RGBA interleavers code that's causing the error checks for 256-bit wide > > vectors (AVX) of 32-bit integers. Your version of GCC is reporting `unsigned > > int` to not be 32-bit in size. I do not know what your distribution is > > doing, but the code is not designed for that circumstance. > > > > FTR, I compile the code with Clang 14.0.6, GCC 12.1 (MSYS flavours CLANG64 > > and UCRT64), and MSVC 17.4 Preview 1. All of them work correctly. > > After further investigation and finding the actual problem I'd say this is > clearly an issue on your side regarding the CMake magic you've implemented > doing the wrong thing since if I compile with -march=x86-64 krita builds > just fine with vectorization/xsimd enabled, but it fails when trying to > build with -march=native on the very same machine with nothing else changed. > That shouldn't be the case and I don't consider this an issue with our > compiler. Probably you should be able to reproduce this when trying to > compile with -march=native as well, not sure what the CMake magic does in > regards to different hardware/processor features though and if that may also > play a role here. march=native? That's the key to this issue, reopening and assigning to myself. Assigning. A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1552 If you can test build Krita with the MR above, it'd be great. (In reply to amyspark from comment #14) > If you can test build Krita with the MR above, it'd be great. Appears to work for me with the changes from the MR. Git commit 9c555836eef341bd6368d6181776838ae7163da0 by L. E. Segovia. Committed on 25/08/2022 at 16:30. Pushed by lsegovia into branch 'master'. xsimd: fix architecture deduction on amd64 with march=native Building Krita with march=native breaks a few assumptions existing in my and Dmitry's code, namely: - KoOptimizedPixelDataScalerU8ToU16 can't deduce the AVX batch type correctly on <= SSE4.1 - KoRgbaInterleavers can't select the correct implementation for AVX, because the AVX2 implementation is ifdef'd in instead of the AVX version These assumptions are correct when building Krita with standard compiler flags, which is why this bug cannot be reproduced in CI or locally out of the box. M +2 -2 libs/pigment/KoOptimizedPixelDataScalerU8ToU16.h M +2 -1 libs/pigment/compositeops/KoRgbaInterleavers.h https://invent.kde.org/graphics/krita/commit/9c555836eef341bd6368d6181776838ae7163da0 Git commit 9add01e5a5818be5e0a6d4d787adb8645b09d049 by L. E. Segovia. Committed on 25/08/2022 at 17:45. Pushed by lsegovia into branch 'krita/5.1'. xsimd: fix architecture deduction on amd64 with march=native Building Krita with march=native breaks a few assumptions existing in my and Dmitry's code, namely: - KoOptimizedPixelDataScalerU8ToU16 can't deduce the AVX batch type correctly on <= SSE4.1 - KoRgbaInterleavers can't select the correct implementation for AVX, because the AVX2 implementation is ifdef'd in instead of the AVX version These assumptions are correct when building Krita with standard compiler flags, which is why this bug cannot be reproduced in CI or locally out of the box. (cherry picked from commit 9c555836eef341bd6368d6181776838ae7163da0) M +2 -2 libs/pigment/KoOptimizedPixelDataScalerU8ToU16.h M +2 -1 libs/pigment/compositeops/KoRgbaInterleavers.h https://invent.kde.org/graphics/krita/commit/9add01e5a5818be5e0a6d4d787adb8645b09d049 |