[assasing123]

In that case is there any chance we could get builds with support for all the AMD specific instruction sets and such? i have a phenom 9500 (changing it soon for a Phenom II 950 BE) ?

[The E]

Yes. If you use Linux and use the march=native compile option. The Visual Studio Compiler only supports stuff that all x86 CPUs understand on its own; anything else has to be handcoded.

[z64555]

It looks like AMD is promoting several SDK's for hardware related capabilities, which at this point may or may not be worth looking into...

http://developer.amd.com/sdks/Pages/default.aspx

[assasing123]

Yes. If you use Linux and use the march=native compile option. The Visual Studio Compiler only supports stuff that all x86 CPUs understand on its own; anything else has to be handcoded.

so is there any of the devs out there who use linux and could compile me a build with support for all the AMD specific instruction that phenom procesors can run? =D please.... i currently get some acceptable frame rate on heavy load missions and stuff but i wouldn't mind getting a nicer buff from the cpu

[The E]

It looks like AMD is promoting several SDK's for hardware related capabilities, which at this point may or may not be worth looking into...

http://developer.amd.com/sdks/Pages/default.aspx

Here's why none of those is of interest to us:

The AMD Accelerated Parallel Processing (APP) SDK is for AMD's GPGPU stuff, which we're not going to use (because if we were to use GPGPU, it would be through OpenCL).
Not rightly sure what the AMD Display Library SDK is for, but it's other GPU stuff.
Open64 is an AMD Compiler, but there's no Windows version available.
The Quad-Buffer SDK is some stereoscopic 3D stuff.
The PMU extension driver is only useful if you're doing profiling on an AMD CPU.
You can probably guess what the Radeon SDK covers.

In short, no, none of the SDKs there have anything to do with the instruction sets supported by AMD CPUs.

so is there any of the devs out there who use linux and could compile me a build with support for all the AMD specific instruction that phenom procesors can run? =D please.... i currently get some acceptable frame rate on heavy load missions and stuff but i wouldn't mind getting a nicer buff from the cpu

There are instructions on the wiki for compiling your own builds. They're not that hard to follow.

[z64555]

In short, no, none of the SDKs there have anything to do with the instruction sets supported by AMD CPUs.

Well that was a helpful venture I made. 

I did take a peek at the libraries though, and the ACML and LibM look like they're CPU specific.

[The E]

ACML is a Fortran library. Not useful for a C/C++ application.
LibM might be interesting (especially the AVX support). Needs investigation.

EDIT: On investigation, it turns out that LibM is an x64 only library. So that's not useful for us at the moment, given that we do not do x64 compiles on windows, at least.

[assasing123]

ACML is a Fortran library. Not useful for a C/C++ application.
LibM might be interesting (especially the AVX support). Needs investigation.

EDIT: On investigation, it turns out that LibM is an x64 only library. So that's not useful for us at the moment, given that we do not do x64 compiles on windows, at least.

hey would compiling on 64 bits be any helpfull if i do have over 4 gigs of ram? or FSO won't get any benefit?

[Dragon]

It's not like FSO is going to use that much RAM anyway (at least, from what I know).
I have 4 gigs of RAM and a 32bit Vista, and that's more than enough for everything I've played so far, from Crysis to ArmAII.

[KyadCK]

ACML is a Fortran library. Not useful for a C/C++ application.
LibM might be interesting (especially the AVX support). Needs investigation.

EDIT: On investigation, it turns out that LibM is an x64 only library. So that's not useful for us at the moment, given that we do not do x64 compiles on windows, at least.

hey would compiling on 64 bits be any helpfull if i do have over 4 gigs of ram? or FSO won't get any benefit?

The only time I ever tried compileing x64 specifically, MSVC++ 2010 threw a hissyfit, besides, FSO only uses like 550-600MB. Anyway, here is a AMD compiled linux build, I havent had the chance to test it yet, so good luck.

(Also, the wiki needs libpng-devel and libjpeg-devel added to dev libraries list for Fedora, took a while to figure those out)

[chief1983]

I always chuckle a little when someone mentions that something should be changed on a wiki page.

[KyadCK]

I always chuckle a little when someone mentions that something should be changed on a wiki page.

Ya, well, I forgot my password for the FSO wiki a while back and even if I didnt I've never modified a wiki page before and linux install instructions is not really the place I would want to experiment.

[jr2]

1) Click "I forgot my password"

2) Before you commit your revision(s), click "Preview" (or perhaps click Preview several times while you are editing it to see what you are doing).

3) Profit!

EDIT: Anyone know if MMX is used by FSO?  If not, it should be.  CPUs that don't support MMX also don't support FSO I'm pretty sure.  Hmm, maybe Retail already included MMX optimizations?  Or is MMX a compiler thing as well?  Anyways, IIRC MMX supposedly added quite a bit of performance heft when dealing with multimedia.  Nowadays, maybe not so noticeable, but every little bit helps.

Is there anyone who knows for sure whether FSO uses MMX optimizations?  Or can explain in plain English why it's not needed / doesn't apply / is not feasible?

[LHN91]

if memory serves MMX was rendered more or less obsolete and redundant by SSE2. It's mentioned in the wikipedia article at least.


EDIT: Which is of no consequence to you with your SSE2less Athlon XP. yeah. I'm going to assume that MMX was an issue when FS2 retail was originally released, so I imagine it gets compiled for automatically.

[z64555]

Seeing as FSO has an ***ton of floating point numbers, I think it's almost a necassity to have some sort of optimization for them.

[The E]

Yes. Which is why we're offering SSE and SSE2 builds. Note that MMX support is not of interest to us, given that MMX instructions are incompatible with x64 processors; We want to add support for new features, not ones that have been deprecated for a decade.

[jr2]

OK, probably showcasing my ignorance here, but ... if they've been depreciated for a decade, then why are they still included with processors today?  Or are 64-bit processors not packing them?  I thought that 64-bit was capable of running 32-bit as well though.

[chief1983]

So you can run apps from a decade ago that require those optimizations to be in place, I suppose.

[LHN91]

Or because they're trivial to leave in the architecture and makes for a really shiny looking list of acronyms on the support page.

[The E]

OK, probably showcasing my ignorance here, but ... if they've been depreciated for a decade, then why are they still included with processors today?  Or are 64-bit processors not packing them?  I thought that 64-bit was capable of running 32-bit as well though.

SSE is a superset (and reimplementation) of MMX. While modern CPUs are capable of reinterpreting MMX code to map onto SSE instructions, using the old MMX instruction set directly is deprecated.

The x87, MMX, and 3DNow! instruction sets are deprecated in 64-bit modes. The instructions sets are still present for backward compatibility for 32-bit mode; however, to avoid compatibility issues in the future, their use in current and future projects is discouraged.

Source: http://msdn.microsoft.com/en-us/library/windows/desktop/ee418798(v=vs.85).aspx