It turns out it's relatively easy to provide support for Windows on ARM.
Unfortunately, it requires building Wine from source, as the version
distributed by Debian (both Bookworm and Sid) is buggy for some tests.
However, building it isn't overly complicated, and can be replaced with
pre-built package once a fixed version lands in Debian Trixie.
Besides that, I also fixed the dynamic linking issue and enabled OpenMP
as for x86 targets.
It has the following advantages:
- It greatly decreases the image size, and improves maintainability of
the package, as we don't rely on third-party image (from Linaro).
- We can build a native image and run it on ARM GitLab runner spreading
the load between different runners, and significantly improving the
speed of execution (over 12 min down to under a minute).
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
- Update LLVM-MinGW.
- Separate out win32 and win64 images. In some scenarios there are
dependency clashes, thus it's easier to simply separate these two
images.
- Fix dynamic library loading. This means we can link dynamically
everything and enable OpenMP for LLVM builds (meaning faster running
tests)
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
- build Docker images
- execute build and test stages
- enable OpenMP for ARMv6 target to improve pipeline speed. This means
that coverage report cannot be generated for this target (no support
for -fprofile-update=atomic).
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
This enables reuse of the Docker build with different runner tags. Will
be used for running native image builds on ARM64 runners.
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
Enables specifying GitLab runner tag on per-job basis. It requires
setting the `RUNNER_TAG_DEFAULT` variable as GitLab CI variable in order
to properly expand it when referenced in templates.
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
Bookworm uses QEMU 7, which is buggy in some contexts (e.g., when
running on aarch64 host).
This change updates QEMU to version 9 from bookworm-backports. It
doesn't affect sid images (which have upstream version 9).
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
- Upload all coverage artifacts in the summary stage. Having all source
coverage reports makes it easier to debug the summary stage behavior
without the need to download each artifact separately.
- Fail if coverage report cannot be generated to prevent silent coverage
report failure, which was possible since coverage report was in the
`after_script` block.
- Always save artifacts, so that it's easier to debug what's happened if
the job failed.
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
Uses the same algorithm, but splits the elements into even-odd groupings
rather than hi-lo. This allows us to do the initial unpack via the
`vec_mul{e,o}` which multiplies 8-bit values and produces 16-bit values.
Replaces
2x `vec_mergeh`
2x `vec_mergel`
2x `vec_mladd`
with
1x `vec_mule`
1x `vec_mulo`
2x `vec_adds`
Slightly improves performance. On a G4, before and after:
over_8888_8888 = L1: 281.39 L2: 243.76 M: 50.19 ( 75.64%) HT: 37.40 VT: 33.08 R: 31.01 RT: 15.47 ( 172Kops/s)
over_8888_8888 = L1: 359.85 L2: 266.58 M: 50.56 ( 76.10%) HT: 37.87 VT: 33.60 R: 31.17 RT: 15.54 ( 172Kops/s)
By using `vec_perm` to select the high-bytes of each 16-bit value in
hi/lo, we can save two `vec_sr` instructions.
Slightly improves performance. On a G4, before and after:
over_8888_8888 = L1: 257.02 L2: 228.77 M: 49.88 ( 75.29%) HT: 37.02 VT: 32.95 R: 30.79 RT: 15.36 ( 171Kops/s)
over_8888_8888 = L1: 281.39 L2: 243.76 M: 50.19 ( 75.64%) HT: 37.40 VT: 33.08 R: 31.01 RT: 15.47 ( 172Kops/s)
In the future if we enable clang-formatting, this will avoid problems
with how it wants to format function arguments.
Also removes some usage of the AVV macro.
I found working in this code very confusing with the number of casts. If
we just use the appropriate vector type, we simplify the code greatly.
Somewhat unexpectedly, this also reduces the instruction counts in some
functions.
This function is only used in vmx_fetch_a8, which is takes packed
unsigned char alpha values and expands them to RGBA8888 with color
components set to 0.
It currently operates by zero-extending the 8-bit alpha values to 16-bit
and then again to 32-bit with different functions (`unpack_128_2x128`
and `unpack_128_2x128_16` respectively). But we can just use the same
function (`unpack_128_2x128`) twice to insert the zeros.
A subsequent commit will change the VMX code to use appropriate vector
types (instead of everything just being a `vector unsigned int` with
casts on most function arguments to select the appropriate `vec_*`
function overload), and removing this function reduces some complexity
from that.
- Upload tar.xz to both x.org and cairographics.org
- Move `git push` and `scp` to the end
- Do most of the work from within build/meson-dist/
- Copy wayland's release.sh's code for getting the project version
- Use bash
Debian image on Docker Hun finally changed mips64el to mips64le bringing
some unification of names at last. Thus to unify everything here, I
renamed all mips64el to mips64le.
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
Remove obsolete workarounds. Rename meson_options.txt to meson.options.
Use c_std=gnu99,c99 to avoid configure-time warning on MSVC:
DEPRECATION: None of the values ['gnu99'] are supported by the c compiler.
However, the deprecated gnu99 std currently falls back to c99.
This will be an error in meson 2.0.
If the project supports both GNU and MSVC compilers, a value such as
"c_std=gnu11,c11" specifies that GNU is preferred but it can safely fallback to plain c11.
Without the change auto-detection of `rvv` support is incomplete as it
assumes `vfloat32m1x4_t` is always present if `vfloat32m1_t` is probed
successfully.
It looks like at least on `gcc-13.3.0` `vfloat32m1_t` is present while
`vfloat32m1x4_t` is not. This causes build failure as:
../pixman/pixman-rvv.c:464:5: error: unknown type name 'vfloat32m1x4_t'; did you mean 'vfloat32m4_t'?
464 | vfloat32m1x4_t sa_sr_sg_sb, da_dr_dg_db, ma_mr_mg_mb;
| ^~~~~~~~~~~~~~
| vfloat32m4_t
The change probes for both types as both are used in `pixman-rvv.c`.
Tested on `gcc-13`, `gcc-14`, `gcc-15`.
Closes: https://gitlab.freedesktop.org/pixman/pixman/-/issues/115
Refer [1], always-inline is not suggested to be used if you have indirect
calls. so replace force_inline with inline to fix error like:
In function ‘combine_inner’,
inlined from ‘combine_soft_light_ca_float’ at ../pixman/pixman-combine-float.c:655:511:
../pixman/pixman-combine-float.c:655:211: error: inlining failed in call to ‘always_inline’ ‘combine_soft_light_c’: function not considered for inlining
Test with gcc-9 and gcc-14, both works well
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115679
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Temporary version pin of gcovr due to errors in coverage report
generation when running with newly released version 8.x.
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
