I'll remove the mcpu=p1 and see what happens.

technically... cvg only cares about usign MMX and 3DNOW. The others are redundant.

There's a 0.6 fps difference in running the timedemos so the optimizations are doing something.

This binary shows the mmx, too, so this one would meet your request fully as think possible for the cvg (instead of the immediately prior one).

Excellent! Please see if this one is better. It has the mmx running for sure, or as sure as the stdout shows.

I wonder if this line is compatible with newer gcc versions: ASFLAGS = -O6.

I'm going to upload a new version shortly that has the few small changes to CVGs source tree (added stipple alpha support). I want you to test that compile for me too then.

Ok, I'll monitor the branch over the next few minutes.

K done

Ok.

Here it is:

__ggorts wrote:

Here it is:

Works perfectly, I guess its a gcc 4.84 or dj 2.05 issue. Having sezero make some compiles for me as well

Great, that's welcome news.

Edit: I'll return in a bit.

Okay, thanks for your help.

😀

Things get more interesting in that my gcc4 builds of glide3x (no matter which version) had proper working SLI on voodoo 5. On sezero's builds I usually got corrupt screens in SLI mode.

After much fiddling around I think I found the issue... Compiling with -O1 instead of -O2 -ffast-math in gcc3 seems to have resolved the issue. The extra flags also appear to be unnecessary as timedemos were exactly the same.

Maybe GCC3 is more aggressive with its floating point math?

You have very interesting findings. On glide3 makefiles I've seen prior, they have this:

1ifeq ($(USE_X86),1)
2CFLAGS += -DGL_X86
3OPTFLAGS ?= -O1 -ffast-math -mcpu=pentium
4else
5CFLAGS += -DGLIDE_USE_C_TRISETUP
6OPTFLAGS ?= -O1 -ffast-math
7endif

I recall that this is documented (maybe a code comment?) somewhere about the troubles of -O2 and resorting to -O1 for building glide3, at least in one or more models (likely originally tested via gcc295). If the timedemo is not significantly different, as you discovered along with these parameter values, then the configuration should be ideal. It is really a surprise, though, that the SLI issues are caused by the compiler version, but I'm glad it's not some obscure bug.

If gcc3 had -O1 -ffast-math working, then it should be the compiling of the C code, maybe rearranged compiled code which is producing an unintended result. However, if I read it correctly, and -ffast-math was disabled, then it could be tested with -O2 where it is disabled there, too; in that case, I would think the floating point math is aggressive, but there are parameters to disable each component of that optimization, so it is possible to test the common problem spots.

Well, I could get nuts and try to find out specifically what switch it is... but considering there isn't even a performance degradation it's probably not worth the effort.

I've noticed in general that playing with optimzer flags usually does no good. Even GCC warns about it. For small, simpler programs it probably makes a difference but large projects like these all it seems to do is introduce subtle bugs.

__ggorts wrote:

You have very interesting findings. On glide3 makefiles I've seen prior, they have this: […]
Show full quote

You have very interesting findings. On glide3 makefiles I've seen prior, they have this:

Copy code to clipboard

1ifeq ($(USE_X86),1)
2CFLAGS += -DGL_X86
3OPTFLAGS ?= -O1 -ffast-math -mcpu=pentium
4else
5CFLAGS += -DGLIDE_USE_C_TRISETUP
6OPTFLAGS ?= -O1 -ffast-math
7endif

I recall that this is documented (maybe a code comment?) somewhere about the troubles of -O2 and resorting to -O1 for building glide3, at least in one or more models (likely originally tested via gcc295). If the timedemo is not significantly different, as you discovered along with these parameter values, then the configuration should be ideal. It is really a surprise, though, that the SLI issues are caused by the compiler version, but I'm glad it's not some obscure bug.

If you can find out specifically, what version you found this information and if there was a comment in the readme/makefile/CHANGES/VERSION/etc I'd like to know about it.

It may be possible at one point someone tried -O2 -ffast-math when a newer GCC update rolled around and it mysteriously started working again.

Also, in the timedemos there is ZERO difference between these flags. SLI or not, they produce exactly the same results down to the tenth digit.