Planning for 0.77 Release

[FLOZi]

Because a hack job is always better than a clean well thought out solution.

[Argh]

Hey, I like hack j... er, yeah.

In this case, it was more just sheer befuddlement than anything else, I just couldn't seem to find the darn reference

At any rate, it's fixed in SVN, and that means that I can finally implement certain things on my UI. Great.

[clericvash]

So what is really left now, last i saw people where talking about is the desyncs which Tobi i think it was submitted a fix for.

So what is left?

[AF]

A few changes were committed by imbaczek recently, though I'm sure they would provide better performance there are one or two qualms.

For example that some things might only take effect if x86 64 is detected, might that not allow subtle compiler differences to creep in causing desync? I assume you know better than me but still Id like to know for myself =p

[imbaczek]

that's actually what I want to test, and no better way of doing it before release than forcing it on people need some testers, though; also, the option is easy to disable (arch=none brings back old behaviour.)

[Auswaschbar]

A few changes were committed by imbaczek recently, though I'm sure they would provide better performance there are one or two qualms.

For example that some things might only take effect if x86 64 is detected, might that not allow subtle compiler differences to creep in causing desync? I assume you know better than me but still Id like to know for myself =p

I regulary test with AMD64 and didn't get more desyncs than anyone with IA32.

Apart from this there is simply no change to make them compile in a similar way because AMD64 cpu's don't have any x87 floating-point-unit.


@imba you should default to march=native (because it picks the right one automatically)

[el_matarife]

Wait, are you saying "lets push out this version and see what happens with the architecture flags and if it breaks we can push out a patch as fast as possible" or what? It'd really suck to totally break Spring when we could just try to get a bunch of people and test it instead.

[jK]

that's actually what I want to test, and no better way of doing it before release than forcing it on people need some testers, though; also, the option is easy to disable (arch=none brings back old behaviour.)

I am thinking you should be using mtune=generic from my understanding as to how GCC's optimization works, at least on the build bot. Only people who are building their own should be using architecture targeted optimizations.

AFAIK mtune enables SSE, etc.

[el_matarife]

that's actually what I want to test, and no better way of doing it before release than forcing it on people need some testers, though; also, the option is easy to disable (arch=none brings back old behaviour.)

I am thinking you should be using mtune=generic from my understanding as to how GCC's optimization works, at least on the build bot. Only people who are building their own should be using architecture targeted optimizations.

AFAIK mtune enables SSE, etc.

Yeah I was reading what imbaczek was saying wrong. I though he was going to enable mtune=native, not just changing the arch sutff around.

[AF]

The last time SSE was enabled the only person who complained was rattle because he had a VIA C7 cpu iirc that did nto support SSE completely.

Assuming that rattle has a new cpu in his machine given that this was ~2006 the event occurred I think tis fair we start using SSE instructions in builds

[imbaczek]

i think it's a sensible proposition for the next version (77b2 or 78b1). too late now.

[Tobi]

Actually it was argued long ago in a bug report that build system should not outsmart you and guess architecture of target platform based on architecture of build platform. (Scons used to do this.)

It's easy to see why, all packages etc. are compiled on build farms with fat CPUs and/or different CPUs from what people run at home, so there just isn't that much much correlation between target platform CPU and build platform CPU. i386 packages may be built on amd64 machine, packages to be run on pentium 4 may be built on a dual quad core, etc.

Also it means if e.g. bibim gets a different server then suddenly the windows binaries will get different optimisation flags, which doesn't make sense.

Also SSE does desync vs x87 last time I tested. I don't care whether AMD64 has x87 built in hardware or not, it can still emulate it in either case

Wrt requiring SSE, anyone any stats on how much ppl actually play games on VIA based CPUs, or other low power CPUs with slimmed down instruction set without SSE? (IOW, it's not a matter of time, SSE-less CPUs are still being produced AFAIK)

[AF]

IIRC that particular via processor was the last SSE-less cpu in its line.

[el_matarife]

Yeah, the VIA CPUs have been supporting SSE since 2003. SSE2/3/4 support is still dicey, but I think every processor that we could realistically expect people to be using on a gaming system will have SSE by now.

[imbaczek]

Tobi: autodetection is never an option; what I want to detect but done sloppily so far was whether the target system is 32 or 64 bits (currently it takes the _builder's_ bit number if asked to detect, on the basis that most people building spring will want it to work on their box - arch=none disabled this). I conciously didn't make -march=native the default.

Re SSE, I can't think of a mainstream cpu more than 4yro not supporting it, need sync tests etc though.

[YokoZar]

Seriously, it's time to go to SSE. Even a damn EeePC netbook supports it.

[panzeriv2]

Why is there a "0.77b1.exe" in the directory...

[Patch]

Why is there a "0.77b1.exe" in the directory...

Now, there is a 76b2 version. Maybe time travel?

But, still crash the air combat test, and still present my graphic problem with water.