Comments (37)
I have a G3 iBook somewhere, I'll see if I can get Linux on it. Leave this open a little longer.
from ioq3.
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.
from ioq3.
+set com_altivec 0
from ioq3.
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.
from ioq3.
yes it build with altivec by default i been modify the makefile for disable the altivec optimization
from ioq3.
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?
from ioq3.
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
from ioq3.
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.
from ioq3.
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
from ioq3.
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
?
from ioq3.
#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.
from ioq3.
ok smc will do it now
from ioq3.
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
from ioq3.
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.
from ioq3.
Tested on Osx PPC and there building and working right.
from ioq3.
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).
from ioq3.
Makefile ppc64 no altivec no 64bit os fixed
Makefile.zip
from ioq3.
here the image of proof of working after fixing the makefile
from ioq3.
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?
from ioq3.
Going once...
from ioq3.
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
from ioq3.
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 ofmake 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?
from ioq3.
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
.
from ioq3.
The c93cfa8 commit resolves the issue - compiles and runs on my PowerPC e5500 machine (non-altivec). Many thanks.
Reference:
from ioq3.
@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.
from ioq3.
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.
from ioq3.
@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
from ioq3.
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 :-)
from ioq3.
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.)
from ioq3.
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.
from ioq3.
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?
from ioq3.
Can ioquake3 run on ppc without changes right now? Since it now depends on SDL 205 or greater without flipping the error in main.
from ioq3.
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...
from ioq3.
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?
from ioq3.
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.
from ioq3.
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.
from ioq3.
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!
from ioq3.
Related Issues (20)
- OpenGL2: Dlight behavior close to surface HOT 1
- Unknown blend mode 'gl_src_color' leads to black menu screen with the PadMod HOT 3
- opengl1: Add software gamma ramps / overbright
- OpenGL2: Lightmap as an environment map renders incorrect with r_mergeLightmaps 1 HOT 1
- OpenGL2: r_ext_multisample > 0 breaks r_drawSunRays 1 (without HDR or FB-MSAA) HOT 1
- OpenGL2: Flares in mirrors calculate wrong depth and have wrong visibility
- Failing to open x64 game in a path with special characters HOT 3
- OpenGL2: The game is too bright and auto-exposure doesn't match the original
- OpenGL2: Curved surfaces don't use dynamic level of detail
- OpenGL2: Stencil shadow volumes are broken (cg_shadows 2) HOT 1
- OpenGL2: r_shownormals 1 is not implemented
- [Warning] Area 51 (2005) HOT 1
- rendering improvements feedback
- OpenGL2: r_greyscale doesn't affect everything
- OpenGL2: r_anaglyphMode causes 2D and HUD models to be transparent
- opengl1: Skybox in OpenGL 1.1 displays black lines at edges
- Add OpenGLES2 renderer HOT 1
- Add pk3 file caching to emscripten port
- Make emscripten port default to 85 FPS, non-V-sync HOT 1
- cgame project is not used HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ioq3.