Builder ffmpeg64-solaris10-i386 Build #13512

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-ffmpeg64-solaris10-i386' triggered this build

Steps and Logfiles:

1. git update ( 5 secs )
   1. stdio
2. shell 'gsed -i ...' ( 0 secs )
   1. stdio
3. shell_1 'gsed -i ...' ( 0 secs )
   1. stdio
4. shell_2 'gsed -i ...' failed ( 0 secs )
   1. stdio
5. shell_3 './configure --samples="../../../ffmpeg/fate-suite" ...' failed ( 7 secs )
   1. stdio
   2. config.log
6. shell_4 'gmake fate-rsync' failed ( 0 secs )
   1. stdio
7. shell_5 '../../../ffmpeg/fate.sh ../../../ffmpeg/fate_config_64.sh' failed ( 0 secs )
   1. stdio
   2. configure.log
   3. compile.log
   4. test.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. Ramiro Polla

   ramiro.pollaohnoyoudont@gmail.com

Timing:

All Changes:

:

1. Change #262831

   Category	ffmpeg
   Changed by	Ramiro Polla <ramiro.pollaohnoyoudont@gmail.com>
   Changed at	Mon 30 Mar 2026 13:38:35
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	a1bfaa0e78c95ab71cd232cf7f43ffca0fa0a055

   Comments

   swscale/aarch64: introduce tool to enumerate sws_ops for NEON backend
   The NEON sws_ops backend will use a build-time code generator for the
   various operation functions it needs to implement. This build time code
   generator (ops_asmgen) will need a list of the operations that must be
   implemented. This commit adds a tool (sws_ops_aarch64) that generates
   such a list (ops_entries.c).
   
   The list is generated by iterating over all possible conversion
   combinations and collecting the parameters for each NEON assembly
   function that has to be implemented, defined by an unique set of
   parameters derived from SwsOp. Whenever swscale evolves, with improved
   optimization passes, new pixel formats, or improvements to the backend
   itself, this file (ops_entries.c) should be regenerated by running:
       $ make sws_ops_entries_aarch64
   
   Sponsored-by: Sovereign Tech Fund
   Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>

   Changed files

   • libswscale/Makefile
   • libswscale/aarch64/ops_entries.c
   • libswscale/aarch64/ops_impl.c
   • libswscale/aarch64/ops_impl.h
   • libswscale/aarch64/ops_impl_conv.c
   • libswscale/tests/sws_ops_aarch64.c
   • tests/ref/fate/source

2. Change #262832

   Category	ffmpeg
   Changed by	Ramiro Polla <ramiro.pollaohnoyoudont@gmail.com>
   Changed at	Mon 30 Mar 2026 13:38:35
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	991611536c28b16e42dca0d86b2986b3ba2b2809

   Comments

   swscale/aarch64: introduce a runtime aarch64 assembler interface
   The runtime assembler interface provides an instruction-level IR and
   builder API tailored to the needs of the swscale dynamic pipeline.
   It is not meant to be a general purpose assembler interface.
   
   Currently only a static file backend, which emits GNU assembler text,
   has been implemented. In the future, this interface will be used to
   write functions dynamically at runtime.
   
   This code will be compiled both for runtime usage to generate optimized
   functions and for build-time usage to generate static assembly files.
   Therefore, it must not depend on internal FFmpeg libraries.
   
   Sponsored-by: Sovereign Tech Fund
   Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>

   Changed files

   • libswscale/aarch64/rasm.c
   • libswscale/aarch64/rasm.h
   • libswscale/aarch64/rasm_print.c

3. Change #262833

   Category	ffmpeg
   Changed by	Ramiro Polla <ramiro.pollaohnoyoudont@gmail.com>
   Changed at	Mon 30 Mar 2026 13:38:35
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	534757926f222804c543e037140189ab8eb677b0

   Comments

   swscale/aarch64: introduce ops_asmgen for NEON backend
   The NEON sws_ops backend follows the same continuation-passing style
   design as the x86 backend.
   
   Unlike the C and x86 backends, which implement the various operation
   functions through the use of templates and preprocessor macros, the
   NEON backend uses a build-time code generator, which is introduced by
   this commit.
   
   This code generator has two modes of operation:
    -ops:
     Generates an assembly file in GNU assembler syntax targeting AArch64,
     which implements all the sws_ops functions the NEON backend supports.
    -lookup:
     Generates a C function with a hierarchical condition chain that
     returns the pointer to one of the functions generated above, based on
     a given set of parameters derived from SwsOp.
   
   This is the core of the NEON sws_ops backend.
   
   Sponsored-by: Sovereign Tech Fund
   Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>

   Changed files

   • libswscale/aarch64/.gitignore
   • libswscale/aarch64/Makefile
   • libswscale/aarch64/ops_asmgen.c
   • libswscale/aarch64/ops_impl.c
   • libswscale/aarch64/ops_impl.h

4. Change #262834

   Category	ffmpeg
   Changed by	Ramiro Polla <ramiro.pollaohnoyoudont@gmail.com>
   Changed at	Mon 30 Mar 2026 13:38:35
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	2517c328fc314c6ea81516499fa7138e395929de

   Comments

   swscale/aarch64: add NEON sws_ops backend
   This commit pieces together the previous few commits to implement the
   NEON backend for sws_ops.
   
   In essence, a tool which runs on the target (sws_ops_aarch64) is used
   to enumerate all the functions that the backend needs to implement. The
   list it generates is stored in the repository (ops_entries.c).
   
   The list from above is used at build time by a code generator tool
   (ops_asmgen) to implement all the sws_ops functions the NEON backend
   supports, and generate a lookup function in C to retrieve the assembly
   function pointers.
   
   At runtime, the NEON backend fetches the function pointers to the
   assembly functions and chains them together in a continuation-passing
   style design, similar to the x86 backend.
   
   The following speedup is observed from legacy swscale to NEON:
   A520: Overall speedup=3.780x faster, min=0.137x max=91.928x
   A720: Overall speedup=4.129x faster, min=0.234x max=92.424x
   
   And the following from the C sws_ops implementation to NEON:
   A520: Overall speedup=5.513x faster, min=0.927x max=14.169x
   A720: Overall speedup=4.786x faster, min=0.585x max=20.157x
   
   The slowdowns from legacy to NEON are the same for C/x86. Mostly low
   bit-depth conversions that did not perform dithering in legacy.
   
   The 0.585x outlier from C to NEON is gbrpf32le -> gbrapf32le, which is
   mostly memcpy with the C implementation. All other conversions are
   better.
   
   Sponsored-by: Sovereign Tech Fund
   Signed-off-by: Ramiro Polla <ramiro.polla@gmail.com>

   Changed files

   • .gitignore
   • ffbuild/common.mak
   • libswscale/aarch64/Makefile
   • libswscale/aarch64/ops.c
   • libswscale/aarch64/ops_impl.h
   • libswscale/aarch64/ops_lookup.h
   • libswscale/ops.c