Hello Guillaume,
Thank you very much for your reply! In the meantime I have researched a bit, and it
appears that "VSX" is a sub-extension that was added to Altivec with POWER7. At least
Wikipedia says so:
https://en.wikipedia.org/wiki/AltiVec#VSX_(Vector_Scalar_Extension)
According to the person who owns this specific PowerMac G5, certain older and newer
versions of x265 *do* compile, but crash with an illegal instruction exception, indicating
that they're attempting to execute operators that the old POWER4 chips simply don't have.
The x265 version my benchmark uses is locked to 2.5+48-bd438ce10843 for
comparability reasons.
I presume that GCC does runtime CPU instruction set extension detection (would make
sense), and doesn't set -mvsx, simply because those CPUs don't even have VSX in the first
place.
I have talked with the person who owns the machine, and he says he might just give you
access (via SSH), just in case you'd be willing to give this a shot.
Creating such a "Big Endian POWER4" branch smells like a lot of work though...
Also: Sad to hear you had your G5 Quad stolen. :( I also had one once, but yep, that
liquid cooling system.. Mine ran out of liquid before I noticed, so it killed one of my
two Laing pumps. :(
In any case, thank you very much!
Best,
Michael
On 18/06/2025 12:24, Guillaume POIRIER wrote:
Hello Michael,
I wrote some of the Altivec code in x264, but my G5 was stolen several
years ago, so I don't have any way to do any work on PPC anymore.
The first error:
__builtin_vsx_lxvw4x_v16qi’ requires the ‘-mvsx’ option
indicates that the build system has to be upgraded to support your compiler
In source/CMakeLists.txt:
472 if(POWER)
473 # IBM Power8
474 option(ENABLE_ALTIVEC "Enable ALTIVEC profiling instrumentation"
ON)
475 if(ENABLE_ALTIVEC)
476 add_definitions(-DHAVE_ALTIVEC=1 -maltivec -mabi=altivec)
477 add_definitions(-flax-vector-conversions -fpermissive)
478 else()
479 add_definitions(-DHAVE_ALTIVEC=0)
480 endif()
481
482 option(CPU_POWER8 "Enable CPU POWER8 profiling instrumentation" ON)
483 if(CPU_POWER8)
484 add_definitions(-mcpu=power8 -DX265_ARCH_POWER8=1)
485 endif()
486 endif()
You can try to add
add_definitions(-mvsx)
around line 475.
The idea is to first ensure that the Altivec code is properly compiled
before trying to figure out the other "error: no matches converting"
errors.
I have no idea if the existing code x265 can work on Big Endian since
I don't know it though.
It's nice to know that in 2025 the G5 Quad still work, as their water
cooling system were notoriously fragile.
Guillaume
On Wed, 18 Jun 2025 at 09:00, Michael Lackner
<michael.lack...@unileoben.ac.at> wrote:
Dear x265 developers and users,
I've been using x265 for cross-platform benchmarking purposes for a while now,
and quite
recently an acquaintance of mine gave me SSH access to quite an interesting
box: A
watercooled Apple PowerMac G5 Quad 2,5 GHz, running Debian 13 Linux with GCC
14.2.0 using
PowerPC CPUs. Both the kernel and the userland are ppc64, so 64-bit Big Endian.
I am aware that x265 does feature some highly optimized code for the PowerPC
"Altivec"
instruction set extension, seemingly targeting the POWER8 architecture. Now
here I am,
trying to compile x265 on what essentially is a POWER4 architecture, and a Big
Endian one
no less (which I guess means lots of trouble).
I found that the Altivec codepath is several tens of thousands of lines long...
When building, the compiler throws tons of errors, here are some random
examples:
"
src/build/x265/source/common/ppc/pixel_altivec.cpp:3577:33: error:
‘__builtin_vsx_lxvw4x_v16qi’ requires the ‘-mvsx’ option
3577 | pix1v = vec_u8_to_s16(vec_xl(0, pix1));
src/build/x265/source/common/ppc/pixel_altivec.cpp:4307:30: error: no matches
converting
function ‘sa8d_8x8_altivec’ to type ‘x265::pixelcmp_t’ {aka ‘int (*)(const
short unsigned
int*, long int, const short unsigned int*, long int)’}
4307 | p.cu[BLOCK_8x8].sa8d = sa8d_8x8_altivec;//sa8d_8x8;
src/build/x265/source/common/ppc/pixel_altivec.cpp:4312:52: error: no matches
converting
function ‘sa8d_8x8_altivec’ to type ‘x265::pixelcmp_t’ {aka ‘int (*)(const
short unsigned
int*, long int, const short unsigned int*, long int)’}
4312 | p.chroma[X265_CSP_I420].cu[BLOCK_16x16].sa8d =
sa8d_8x8_altivec;//sa8d8<8, 8>;
| ^~~~~~~~~~~~~~~~
"
I attempted to switch Altivec support off in CMakeLists.txt, and indeed, after
doing so
x265 compiled and ran just fine, when built purely from C/C++ code with no
Altivec
optimizations enabled.
So here comes my question: Is there a reasonably easy way to make that
optimized Altivec
codepath compile and work on a set of old Big Endian POWER4 chips like these?
Additionally, it has to be 64-bit, because my benchmark has x265 configured in
such a way
that it requires almost 16 GiB of RAM when run (encoding 8K content,
parameterised with a
focus on parallelisation).
I guess I shouldn't get my hopes up here, because this is a niche of niches,
but if
possible, I'd love to include yet another microarchitecture into the list of
systems that
my x265-based benchmark supports out-of-the-box. :)
It appears that the development of that codebranch started by adapting source
code from
x264. x264 does actually compile and run with Altivec support on that machine,
so that's
my silver lining on the horizon here.
If it's too hard (and/or too expensive), I guess I'll still support the
platform, but
sadly with Altivec support disabled.
Thank you all!
Best regards,
Michael
--
____________________________________________________________________________________
Michael Lackner
Lehrstuhl für Informationstechnologie | Chair of Information Technology
Montanuniversität Leoben | Technical University of Leoben
Roseggerstraße 11, A-8700 Leoben | Roseggerstraße 11, A-8700 Leoben
Telefon: +43 3842 402 1505 | Phone : +43 3842 402 1505
E-Mail : michael.lack...@unileoben.ac.at | E-Mail:
michael.lack...@unileoben.ac.at
Web : https://infotech.unileoben.ac.at | Web :
https://infotech.unileoben.ac.at
____________________________________________________________________________________
VERSETZ' BERGE | MOVE MOUNTAINS
_______________________________________________
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel