Name the feature "arm_crc" rather than plain "crc", to make it
clear that this is about a CPU feature extension, not CRC
implementations in general.
This requires dealing with the extension slightly differently
than other extensions, as the name of the feature and the
".arch_extension" extension name differ.
Naming it with an "arm" prefix rather than "aarch64", as the
CPU extension also is available in 32 bit ARM form, even though
we don't intend to use it there.
This allows naming the ffmpeg wide feature with a different (more
elaborate) name than the raw cpu extension as it is spelled in
the ".arch_extension" directives.
We use a dummy aarch64 feature to work around an issue in older
Clang, where an .arch line such as ".arch armv8.2-a" doesn't take
effect immediately, while one like ".arch armv8.2-a+feature" works.
Previously, we used "crc" for this dummy feature to add (as an
old feature that would be supported widely by old toolchains).
But as we may want to actually use crc features and detect whether
they are supported, we may want to switch to another feature.
Use the "fp" feature instead, for the purposes of this extra
feature in the .arch lines. (The "fp" feature indicates floating
point support, which is implicitly part of the baseline feature
set anyway.)
Implemented the algorithm described in the paper titled
"Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction"
by Intel.
It is not used yet; the integration will be added in a separate commit.
Observed near 10x speedup on AMD Zen4 7950x:
av_crc_c: 22057.0 ( 1.00x)
av_crc_clmul: 2202.8 (10.01x)
This is in preparation for adding checkasm support for av_crc(),
which will always call the same function, but uses different CRC
tables to distinguish different implementations.
This reuses checkasm_check_func() for this; one could also add
a new function or use unions. This would allow to avoid casting
const away in the crc test to be added. It would also allow
to avoid converting function pointers to void* (which ISO C
does not allow).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The compiler was emitting a warning on every Cairo function replaced by
the `MOCK_FN_n` macros:
warning: 'cairo_...': redeclared without dllimport attribute after
being referenced with dll linkage
The macro `CAIRO_WIN32_STATIC_BUILD` prevents the attribute `dllimport` on
the declarations for these functions.
Signed-off-by: Ayose <ayosec@gmail.com>
Colors expressions (like `#RRGGBB`) can now be used as arguments for `setvar`
and `call`.
The trick of setting a variable with a `0xRRGGBBAA` value is not valid anymore.
Signed-off-by: Ayose <ayosec@gmail.com>
To be able to reuse colors from the original frame, the last value returned by
`p()` is tracked in the eval state, and if it is assigned to a variable, the
original color components are copied to `color_vars`. Thus, commands like
`setcolor` and `colorstop` can use those variables:
setvar pixel (p(0, 0))
...
setcolor pixel
`fate-filter-drawvg-video` now also verifies the `p()` function.
Signed-off-by: Ayose <ayosec@gmail.com>
The arguments for `setvar` and `call` commands can be colors (like `#rrggbb`).
This replaces the previous trick of using `0xRRGGBBAA` values to use colors as
procedure arguments.
The parser stores colors as the value expected by Cairo (a `double[4]`). This
array is allocated on the heap so the size of the union in `VGSArgument` is
not increased (i.e. it is still 8 bytes, instead of 32).
Signed-off-by: Ayose <ayosec@gmail.com>
In libcairo, colors are defined as 4 separate components, and each one is double
between 0 and 1. Before this commit, colors stored in variables (like `defhsla`)
were converted to a `0xRRGGBBAA` value, which introduced some issues due to
rounding errors.
Now, when a color is assigned to a variable, the original values (a `double[4]`)
are stored in a dedicated array (`color_vars`), so no conversion is needed.
This change also reduces the cost of reading a color from a variable (no need
for `av_be2ne32`, or the `color[i] / 255` operations).
Signed-off-by: Ayose <ayosec@gmail.com>
It only contains a single field, so add this directly to MPVContext
and remove private_ctx. This avoids an indirection in
ff_h261_loop_filter().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are only used by the decoder (which has them twice, because
the IntraX8Context contains a WMV2DSPContext whose put_mspel_pixels
functions were unused), so move them there.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
WMV1 and WMV2 use other scantables and therefore
ff_msmpeg4_common_init() reinitializes them. Yet WMV2
also uses a different IDCT overwriting the ordinary one,
so that the IDCT permutation changes and therefore
ff_wmv2_common_init() (called after ff_msmpeg4_common_init())
needs to reinitialize the scantables again.
Avoid this by calling ff_wmv2_common_init() in
ff_msmpeg4_common_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When a frame is exported to DRM, it may be written to to read to in an asyncronous fashion. Make sure, on unmap of a Vulkan frame that was mapped to DRM, to import any fences that were put on the dmabuf
Not entirely sure if it should instead use some entirely different
approach here, given that images exceeding 2GB don't seem that crazy
to me, but so far processing such images results in a heap overflow,
since the size addition overflows and a much too small packet is
allocated and its size never checked again when writing into it.
Fixes #YWH-PGM40646-32
Martin Storsjö