[x265] [EXT] Re: Compiling x265 and its Altivec code branch on Big Endian ppc64

Michael Lackner michael.lackner at unileoben.ac.at
Wed Jun 18 11:44:33 UTC 2025


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.lackner at 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.lackner at unileoben.ac.at  | E-Mail: michael.lackner at unileoben.ac.at
Web    : https://infotech.unileoben.ac.at | Web   : https://infotech.unileoben.ac.at
____________________________________________________________________________________

VERSETZ' BERGE | MOVE MOUNTAINS



More information about the x265-devel mailing list