please remove altivec optimization for linux PPC

[tlosm]

please remove altivec optimization in makefile linux ppc because on powerpc cpu without altivec it made crashing with coredump after building.
Tested on P5020 freescale 2ghz

[ensiform]

+set com_altivec 0

[icculus]

I'm pretty sure the code should have noticed the CPU doesn't support AltiVec and set that cvar to zero by default. Might actually be a bug.

[tlosm]

yes it build with altivec by default i been modify the makefile for disable the altivec optimization

[icculus]

Okay, this is weird:

We check for Altivec support at runtime in Com_Init(), which calls Com_DetectAltivec(), which calls Sys_GetProcessorFeatures()...which never ever checks for Altivec support. That is a bug too; just pushed a fix for it.

So that being said, I get the impression this isn't a problem with this non-Altivec CPU running our custom Altivec code, but rather we are instructing the compiler to build a binary that uses Altivec for generic math, like the amd64 version might use SSE2 instructions instead of the FPU.

So...this is still a legit bug. Is it -maltivec that's causing the problem? We should at least have a flag to avoid compiling with that flag. That flag exists because we (historically) needed it to enable the Altivec extensions for our custom code, but the compiler wouldn't otherwise generate Altivec instructions...apparently this isn't true anymore?

[tlosm]

Yes and no, pratically now there are PowerPc with altivec and PowerPc without
Now new desktop machine are without altivec support . P1020, P5020 and Amcc 460.
Old G4 and G5 have altivec and Servers with e6500 and Power7 cpus.
In any way in my personal experiences altivec inside of quake3 dont change performances ;-)

Luigi

[icculus]

My point was -maltivec (if that's the actual flag causing problems) use to not generate any Altivec instructions by itself, but rather allowed you to use the C intrinsic functions for altivec (vec_splat() and all the others).

If it's now generating Altivec code that we can't carefully gate off behind the com_altivec cvar, we need to find a way to make this do the right thing again.

[tlosm]

Gordon , i found another issue i face it on Quad G5 and On X5000 too ..
this is in /libcurl-7.35.0/curlrules.h

dont build exit with error because this cant be negative
#define CurlchkszEQ(t, s) sizeof(t) == s ? 1 : -1
#define CurlchkszGE(t1, t2) sizeof(t1) >= sizeof(t2) ? 1 : -1

i switched in:
#define CurlchkszEQ(t, s) sizeof(t) == s ? 1 : 1
#define CurlchkszGE(t1, t2) sizeof(t1) >= sizeof(t2) ? 1 : 1

and build was continue

[smcv]

If [-maltivec is] now generating Altivec code that we can't carefully gate off behind the com_altivec cvar

That's what the option is primarily documented to do, at least. From the gcc man page (my emphasis):

      **Generate code that uses (does not use) AltiVec instructions**, and
      also enable the use of built-in functions that allow more direct
      access to the AltiVec instruction set.

Could the functions that call Altivec intrinsics perhaps be moved into a separate translation unit (.o) that is the only thing compiled with -maltivec?

In Debian we have an open bug report asking to not use -maltivec on at least the powerpcspe port (PowerPC with Signal Processing Extensions, an automotive/industrial variant of PowerPC with its own weird extensions using the same opcodes as Altivec; not to be confused with the Synergistic Processing Element in the PS3's Cell processor, which is something completely different). Strictly speaking I shouldn't be using Altivec on ordinary PowerPC either, because the ABI we officially target is a baseline pre-Altivec PowerPC; but I only have a G4, and nobody else in Debian has been able to confirm whether a non--maltivec build actually works on a non-Altivec PowerPC.

Does everything (in particular the QVM bytecode interpreter) work correctly on a non-Altivec CPU in a build without -maltivec?

[smcv]

#define CurlchkszEQ(t, s) sizeof(t) == s ? 1 : -1
#define CurlchkszGE(t1, t2) sizeof(t1) >= sizeof(t2) ? 1 : -1

This looks unrelated. Please open separate issues for separate compilation failures.

[tlosm]

ok smc will do it now

[tlosm]

smc , i cant test on linux ppc because on quad g5 too ioquake3 dont build because the sdl2 issue.
i will make another test on OsX Leopard and will check if there will build ok
but like i explained before all software who use sdl2 here build and work:
eg quake spasm, doom3, Fs-uae, Qemu 2.5

[icculus]

That's what the option is primarily documented to do, at least.

That's not what it used to do, as far as I recall.

Yes, unless there's a command line that only enables the Altivec C extensions, we'll need to move the Altivec-specific pieces to their own file and use -maltivec only there. That's frustrating.

Maybe something like -maltivec -mabi=no-altivec works? Or -maltivec -mcpu=7400 ?

Also: Is there an -faltivec option now? That's what Apple used in their GCC, and it didn't specify any codegen behaviors beyond the C extensions were available for use. Maybe mainline GCC sync'd up to that?

--ryan.

[tlosm]

Tested on Osx PPC and there building and working right.

[icculus]

Tested on Osx PPC and there building and working right.

Yes, this is a problem with the GCC that ships with Linux, which is a different fork of GCC (and specifically: has different options for Altivec support on the command line).

[tlosm]

Makefile ppc64 no altivec no 64bit os fixed
Makefile.zip

[tlosm]

here the image of proof of working after fixing the makefile

[smcv]

Here is that change in a more useful form:

diff --git a/Makefile b/Makefile
index d65d9bf..b333ace 100644
--- a/Makefile
+++ b/Makefile
@@ -340,11 +340,11 @@ ifneq (,$(findstring "$(PLATFORM)", "linux" "gnu_kfreebsd" "kfreebsd-gnu" "
gnu")
     HAVE_VM_COMPILED=true
   else
   ifeq ($(ARCH),ppc)
-    BASE_CFLAGS += -maltivec
+    BASE_CFLAGS +=
     HAVE_VM_COMPILED=true
   endif
   ifeq ($(ARCH),ppc64)
-    BASE_CFLAGS += -maltivec
+    BASE_CFLAGS += -g -O2 -mcpu=e5500 -mno-altivec -mtune=e5500
     HAVE_VM_COMPILED=true
   endif
   ifeq ($(ARCH),sparc)
@@ -392,7 +392,7 @@ ifneq (,$(findstring "$(PLATFORM)", "linux" "gnu_kfreebsd" "kfreebsd-gnu" "gn
u")
     BASE_CFLAGS += -m32
   else
   ifeq ($(ARCH),ppc64)
-    BASE_CFLAGS += -m64
+    BASE_CFLAGS += -m32
   endif
   endif
 else # ifeq Linux
@@ -412,11 +412,11 @@ ifeq ($(PLATFORM),darwin)
     -DMAC_OS_X_VERSION_MIN_REQUIRED=1050

   ifeq ($(ARCH),ppc)
-    BASE_CFLAGS += -arch ppc -faltivec
-    OPTIMIZEVM += -O3
+    BASE_CFLAGS += -arch ppc
+     OPTIMIZEVM += -O3
   endif
   ifeq ($(ARCH),ppc64)
-    BASE_CFLAGS += -arch ppc64 -faltivec
+    BASE_CFLAGS += -g -O2 -mcpu=e5500 -mno-altivec -mtune=e5500
   endif
   ifeq ($(ARCH),x86)
     OPTIMIZEVM += -march=prescott -mfpmath=sse
@@ -724,11 +724,11 @@ ifeq ($(PLATFORM),openbsd)
     HAVE_VM_COMPILED=true
   else
   ifeq ($(ARCH),ppc)
-    BASE_CFLAGS += -maltivec
+    BASE_CFLAGS += -g -O2 -mcpu=e5500 -mno-altivec -mtune=e5500
     HAVE_VM_COMPILED=true
   endif
   ifeq ($(ARCH),ppc64)
-    BASE_CFLAGS += -maltivec
+    BASE_CFLAGS += -g -O2 -mcpu=e5500 -mno-altivec -mtune=e5500
     HAVE_VM_COMPILED=true
   endif
   ifeq ($(ARCH),sparc64)

I'm fairly sure that isn't the correct patch, but it's a step in the right direction. Thank you for testing this.

If you go back to the original ioquake3 Makefile, and then remove all mentions of -maltivec or -faltivec without making other changes, does that also work?

[NuclearMonster]

Going once...

[icculus]

I have a G3 iBook somewhere, I'll see if I can get Linux on it. Leave this open a little longer.

[tlosm]

hi sorry for late reply. on G3 with linux you will face the same issue . the issue is
first where constants ppc64 is present the ioquake will build and result with a core dump if the OS is ppc32 and the kernel is ppc64 (ubuntu mate, lubuntu, debian) this issue come on ppc64 machine.
Plus if the altivec optimization is present will build with a core dump in not altivec machines. I fixed the makefile and all build without issue on fedora 25 full ppc64 and on Ubuntu Mate PPC64 kernel PPC32 Os. this on P5020/P5040 ammc 460
On G5 Quad ioquake build and work without issue on linux ubuntu mate (it is with altivec) but need fix the ppc64 . On Fedora build and work totally without issue.

use the -maltivec or -faltivec option will not fix the issue on not altivec machine

[smcv]

I fixed the makefile

This is not enough information to make a change, because we do not know what "fixed the makefile" means.

The change that I quoted in #181 (comment) (which is what you attached in #181 (comment) converted into a form we can review) is not suitable for applying to ioquake3, because it is really several changes:

• stop enabling Altivec (remove -faltivec, -maltivec) - I expect that this is necessary
• make PPC64 builds turn into PPC32 - this is not correct, use make ARCH=ppc if you want to build a PPC32 version of ioquake3 on a PPC64 machine
• use a non-default optimization level on PPC64 - why?
• enable debug symbols - use make debug instead of make release if this is what you want
• build PPC64 binaries and some PPC32 binaries to require and be optimized for E5500 family CPUs - this is not OK, generic PPC64 binaries should be built for a baseline (minimal) CPU and optimized according to gcc's defaults

Please test the change that I asked you to test: remove all mentions of -faltivec or -maltivec from the Makefile, make no other changes, and tell us whether that works. If it works, great, we can apply that change. If it doesn't work, please say so, clearly and unambiguously.

If removing all the -faltivec and -maltivec doesn't work, but you can find something that does, please tell us a minimal change to the Makefile that works. Be specific and precise. Replacing all mentions of -maltivec with -mno-altivec might work, for example?

[smcv]

Please try smcv@c93cfa8c which I think might address this? (Untested, I don't have a non-Altivec PowerPC)

To build a 32-bit binary on a 64-bit kernel, compile with make ARCH=ppc.

[casey-ac]

The c93cfa8 commit resolves the issue - compiles and runs on my PowerPC e5500 machine (non-altivec). Many thanks.
Reference:

[smcv]

@casey-ac, would you mind testing the equivalent OpenArena change for me? I see from your screenshot that you are (or were) using Ubuntu 16.04 - I can send you .dsc source packages that should compile fine on Ubuntu. Please email smcv at debian dot org if you can help with that.

[grepwood]

What's exactly wrong with altivec? I run ioquake3 (not from git) on gentoo on a ps3 sometimes and it doesn't have any issues like described here.

[smcv]

What's exactly wrong with altivec?

It's an optional CPU extension that not all PowerPC CPUs have, similar to MMX, SSE, SSSE etc. on x86. If ioquake3 is built with Altivec instructions, it will only work on PowerPC CPUs that support Altivec.

Unlike x86 extensions, Altivec isn't ubiquitous even on newer CPUs: new CPUs are still being produced that don't support it.

I run ioquake3 (not from git) on gentoo on a ps3 sometimes

The PPE, the PS3's main CPU, is one of the examples of a PowerPC that does support Altivec (it's compatible with the PowerPC 970 family, aka Apple G5).

Apple G3 and Freescale e5500 are examples of PowerPC CPUs that don't support Altivec.

[grepwood]

@smcv Understandable. What code is affected by the removal of AltiVec? There are ways to determine AltiVec support in Linux much like you would with cpuid in x86, see projg2/cpuid2cpuflags#2

[smcv]

What code is affected by the removal of AltiVec?

Potentially any floating-point code emitted by the compiler.

ioquake3 already conditionalizes explicit uses of vector instructions on SDL_HasAltiVec() via com_altivec, but as discussed in 2016 (see above) that is no longer enough, because -maltivec doesn't just enable explicit vector intrinsics: it also gives the compiler permission to generate Altivec opcodes for ordinary C code that the compiler detects as potentially benefiting from Altivec.

A generic ioquake3 binary that can run on non-Altivec machines can't use -maltivec, except for separate Altivec-specific translation units (roughly, .c files) that are only conditionally called into. Having one Altivec function within a larger translation unit isn't enough separation.

I suspect there is a fairly low limit to how much restructuring the ioquake3 maintainers are going to want to do to get the benefit of Altivec (is it measurable?) on Apple machines last sold in 2007, and the minority of PS3s that are the original generation of hardware and haven't received the 2010 firmware change that prevents them from booting Linux :-)

[icculus]

I know we're probably beating a dead horse here, but...can we move all our altivec-specific code to a file we compile with -maltivec and not use -maltivec on any other source files? That should let us keep the Altivec optimizations that we care about and select them at runtime and also make sure the same binary will run on non-Altivec hardware. I'm pretty confident that we don't need all the floating point math in the game to use the Altivec unit, since this game ran on blueberry iMacs originally.

(But maybe have an option for that, instead of the other way around.)

[smcv]

can we move all our altivec-specific code to a file we compile with -maltivec and not use -maltivec on any other source files?

I think that can work. If you think that's worth the effort, and there's going to be someone available to test it on non-Altivec-capable hardware, I can prepare a patch that does that. @casey-ac tested #337, perhaps they could test a new patch?

I'd want to be sure that it had a decent chance of getting merged before doing that, though.

(But maybe have an option for that, instead of the other way around.)

Sorry, I'm not sure I parsed what you want correctly. There are three reasonable things to do on PowerPC:

• No Altivec at all (slowest, most compatible)
• Selectively use -maltivec for a couple of files with targeted Altivec-specific versions of functions
• -maltivec everywhere (fastest, least compatible)

Which one do you want to be the default and which others do you want to have available?

For Debian powerpcspe (an obscure PowerPC variant) it needs to be possible to get the first of those three options (it's OK if it's necessary to ask for it explicitly), because -maltivec doesn't work/exist there. Generic PowerPC, including Debian powerpc, should ideally be the second one if it works. Current upstream ioquake3 is the third. I don't know how much performance difference it actually makes.

The patch I proposed in #337 results in the first of those options by default, or the third if you ask for it.

[icculus]

I moved all the Altivec code to its own source files over here: #367

But I don't personally want to bother with the Makefile, if someone else wants to handle that.

Which one do you want to be the default and which others do you want to have available?

(Apply my patch, then) use -maltivec on code/client/snd_altivec.c and code/renderergl1/tr_altivec.c if we're on a PowerPC machine, unconditionally. I think we can just let people use Makefile.local if they are certain they have a vector unit and want every file built with -maltivec for the floating point performance boost. Maybe some hardcore user or a G4-specific distro will want to do that. I wouldn't bother making it an option you enable in the Makefile.

It's safe to comple snd_altivec.c and tr_altivec.c everywhere, they'll just #ifdef down to nothing.

The macOS pieces of the Makefile can just use -faltivec like they always do; Apple's PPC compiler just uses this to enable the Altivec intrinsics, not to use Altivec for all floating point like GCC does. But someone can make it match up with GCC if they want.

Does that sound okay?

[ensiform]

Can ioquake3 run on ppc without changes right now? Since it now depends on SDL 205 or greater without flipping the error in main.

[smcv]

Can ioquake3 run on ppc without changes right now?

On Linux, with Altivec-capable CPUs (because of this issue) and a system copy of SDL2, I don't see why not. On macOS with the bundled copy of SDL2, perhaps not, but there is no vendor-supported macOS version that still works on PPC anyway...

[ensiform]

But I just think it would be weird to put in a hack to disable that version check just for that.

No chance of newer sdl2 for ppcmac at least?

[icculus]

Last we checked (not recently), SDL2 could be built for PowerPC Mac OS X with a few minor patches; so leaving it in the Makefile for ioquake3 doesn't hurt anything if someone gets bold enough to try it.

(The general problem SDL runs into there isn't CPU compatibility, but OS and compiler version; we're starting to use APIs that don't exist in OS X 10.5, and syntactic sugar that doesn't exist in their PowerPC tools.)

PowerPC Linux (and OpenBSD, embedded things, etc) are more reasonable targets at this point, as far as ioquake3 is concerned, and the altivec changes we're discussing here will be of good use to them.

[zturtleman]

Regarding Ensiform's comments;

The ioq3 universal app bundle built from git master still works on macOS 10.5 PowerPC using SDL 2.0.1 included in the ioq3 repo. The PowerPC build is also run by macOS 10.5 x86 and x86_64 due to SDL 2.0.5 dropping support for macOS 10.5. (The minimum macOS version by arch is listed in the app bundle Info.Plist.)

ioq3 only requires SDL 2.0.5 at run-time if compiled against 2.0.5 or newer. This allows macOS 10.5 PowerPC and old GNU/Linux distros (such as Ubuntu Trusty on Travis-CI) to still be able to compile and run ioq3.

[icculus]

I believe that the merge of #368 resolves this issue. Let me know if this is still giving you problems on various PowerPC setups and we can reevaluate, though!