Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: jr2 on November 09, 2011, 04:35:32 pm
-
Topic created as a split from the original Shadows in FSO thread. This thread can discuss hardware support as necessary but keep in mind that the shadow support is in its early stages and will require a machine of capable specs. Thanks folks :) - Fineus
Yeah... :(
(http://i40.tinypic.com/nbcgzq.png)
-
8 year old cpu, time for an upgrade maybe? :p
-
Yes, however
1) I don't have the $$$ yet
2) I have a laptop with an AMD dual-core Z80 (or is it Z90? I forget) CPU and ATI 3200 GFX, so I'm not quite up the creek without a paddle yet
-
Yes, however
1) I don't have the $$$ yet
2) I have a laptop with an AMD dual-core Z80 (or is it Z90? I forget) CPU and ATI 3200 GFX, so I'm not quite up the creek without a paddle yet
Why would you even try to run a shadows build with a CPU like this? Let me guess, you have an NVIDIA Geforce4 or something too?
Makes no sense, bro.
-
Yes, however
1) I don't have the $$$ yet
2) I have a laptop with an AMD dual-core Z80 (or is it Z90? I forget) CPU and ATI 3200 GFX, so I'm not quite up the creek without a paddle yet
Why would you even try to run a shadows build with a CPU like this? Let me guess, you have an NVIDIA Geforce4 or something too?
Makes no sense, bro.
It should be able to run, albeit with some performance loss...
-
Yes, however
1) I don't have the $$$ yet
2) I have a laptop with an AMD dual-core Z80 (or is it Z90? I forget) CPU and ATI 3200 GFX, so I'm not quite up the creek without a paddle yet
Why would you even try to run a shadows build with a CPU like this? Let me guess, you have an NVIDIA Geforce4 or something too?
Makes no sense, bro.
Ha. No. Mobo is MSI 6570E (nForce2 Ultra 400 chipset), ATI Radeon HD 3450 on AGP8X, 2GB RAM (400MHz, dual-channel mode), Windows 7 (32-bit ofc, Athlon XP is 32-bit CPU), 2x2TB SATA hard disks (although, they are WD Green HDs so performance isn't really great).
So. Old, yes. ****ty, no. If that answers any curiosities...
-
Disagree. A Radeon 3450 is really really bad.
-
Disagree. A Radeon 3450 is really really bad.
Really bad, yes. Really bad enough so you cant play with shadows, no.
I say no, because I have a friend who has a Radeon 3450 with an Athlon x2 and it runs quite well (about 15 fps in calm areas) :pimp:
-
Well, it was the best AGP card that $40 could get me. It was recommended IIRC by either The_E or Jeff Vader when I said I was looking for a $40 card to replace my X1650 (which has horrific OGL support, thx ATI, you suck; AMD, please fixx0r your n00b minion kthxbai).
Anyways...
-
To discuss you ****ty graphics cards i would recommend a different thread.
-
:/ Sorry.
-
Disagree. A Radeon 3450 is really really bad.
Really bad, yes. Really bad enough so you cant play with shadows, no.
I say no, because I have a friend who has a Radeon 3450 with an Athlon x2 and it runs quite well (about 15 fps in calm areas) :pimp:
>runs quite well in calm areas
>15 fps
What am I reading here? :p
-
Disagree. A Radeon 3450 is really really bad.
Really bad, yes. Really bad enough so you cant play with shadows, no.
I say no, because I have a friend who has a Radeon 3450 with an Athlon x2 and it runs quite well (about 15 fps in calm areas) :pimp:
>runs quite well in calm areas
>15 fps
What am I reading here? :p
something better than nothing, rite? I remember back in the day on my old comp. Freespace used to run at arround 18~20 FPS (Media VPs 3.6.10 w/o advanced.vp) in calm areas. :P
-
Same kinda thing. I had the option between a P4 1.8 with a PCI slot Geforce FX5500, which, w/o advanced, ran 20-30 fps in calm areas and chugged everywhere else; or a laptop with an intel GMA950. Sadly, the GMA actually handled it better XD
-
Heh, on 3.6.7 I had put FSO on an AMD K6-2 500MHz w/ PCI BFG 5500, 256 MB RAM, Win ' 98 IIRC... or maybe it was 512MB and XP, I forget. It did run, however. Just had to take out advanced MVPs and tone the settings down a bit.
-
So, jr2, are you asking for support for 3DNow!, MMX, and SSE?
-
SSE support is already incorporated into FSO. 3DNow! and MMX? Sure! :D Although I'm betting MMX is already built in as all processors since like 1996 have it.
-
SSE support is already incorporated into FSO. 3DNow! and MMX? Sure! :D Although I'm betting MMX is already built in as all processors since like 1996 have it.
Just a warning, 3DNow! is AMD exclucive and starting with Bulldozer AMD no longer supports it.
-
SSE support is already incorporated into FSO. 3DNow! and MMX? Sure! :D Although I'm betting MMX is already built in as all processors since like 1996 have it.
As far as I know, standard C/C++ programs simply compile into assembler that the CPU can understand. Hardware microprograms and special registers can only be used if your compiler is configured to use it and/or the code itself has been structured around said features.
A quick Q: How is the SSE builds different from the standard builds in terms of organization, additional functions, datatypes, etc.?
-
Codewise, there are no differences. The only difference between the no SSE, SSE and SSE2 builds are the compiler settings, that is, the compiler is allowed to use additional optimizations there.
-
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) ?
-
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.
-
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 (http://developer.amd.com/sdks/Pages/default.aspx)
-
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
-
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 (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.
-
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. :P
I did take a peek at the libraries though, and the ACML and LibM look like they're CPU specific.
-
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.
-
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?
-
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.
-
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 (http://www.mediafire.com/?ggynxvujgryc18l), 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)
-
I always chuckle a little when someone mentions that something should be changed on a wiki page.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
So you can run apps from a decade ago that require those optimizations to be in place, I suppose.
-
Or because they're trivial to leave in the architecture and makes for a really shiny looking list of acronyms on the support page.
-
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
-
Besides stuff like SSE, what are some other hardware related features that we can look at?
Hyperthreading comes to my mind, oddly.
-
Hyperthreading is essentially make a single core look like 2 to the OS. Completely useless to us at the moment as the engine is entirely single-threaded.
-
I'm gonna go out on a limb here... I realize that many of you think that you can figure out how to get more FPS by "simply adding some new hardware support"...
My bet is that the coders know the solutions out there, have looked at most of them, and have added what they consider to be worth the work. I doubt we are going to come up with something that they hadn't thought of and/or already dismissed.
-
what mjn said. Also if u use linux and dont manage to compile something WITH instructions i suggest you buy a mac or become an hero.
-
what mjn said. Also if u use linux and dont manage to compile something WITH instructions i suggest you buy a mac or become an hero.
Become a hero. Because heroes are FTW.
(http://i42.tinypic.com/2luqs7k.jpg)
Stay with Linux. Get it if you don't have it. Because Linux is 1337 and 4w350m3. But retain dual-boot with M$ WinDOwS. For nostalgia's sake, and because WINE doesn't run all winDOwS programs yet.
(http://i41.tinypic.com/23sh08.jpg)
-
I'm gonna go out on a limb here... I realize that many of you think that you can figure out how to get more FPS by "simply adding some new hardware support"...
My bet is that the coders know the solutions out there, have looked at most of them, and have added what they consider to be worth the work. I doubt we are going to come up with something that they hadn't thought of and/or already dismissed.
No fun. :(
-
Yeah... I (and maybe others) keep hoping to see something in the forest that the coders may perhaps have missed in the trees of coding. Heh. Reality isn't that easy, hmm? :doubt:
-
Besides stuff like SSE, what are some other hardware related features that we can look at?
Hyperthreading comes to my mind, oddly.
if i were to name anything:
x64 builds.
if anything to allow the use of bigger datatypes and 64-bit instructions. you could double the precision in things like the physics maths, allowing for more range in velocity, and more available space in which to have a mission. not sure what the broader implications are of such a thing or how much work that would entail. but its probibly the single thing you could do to give 64 bit users more go. still you wouldn't get this under 32 bit, and it would be so radical that noone would really want to do it. especially when you still got people running 32 bit because they think that support for more memory is the only reason to run a 64 bit os.
-
Hyperthreading comes to my mind, oddly.
Which is not something we as developers need to be aware of. Implementing multithreading support is one thing, but we're not going to add code to cater to the peculiarities of a hyperthreading setup.
-
I thought once multithreading support was added, hyperthreading users would automatically see a boost; the CPU takes care of the rest?
-
Hyper-threading requires not only that the operating system support multiple processors, but also that it be specifically optimized for HTT[1] (http://software.intel.com/en-us/articles/required-components-interchangeability-list-for-the-intel-pentiumr-4-processor-with-ht-technology), and Intel recommends disabling HTT when using operating systems that have not been optimized for this chip feature
:blah:
Hyper-threading works by duplicating certain sections of the processor—those that store the architectural state—but not duplicating the main execution resources
:blah: :blah:
Hmm. Yeah. I don't think I want to touch that topic again for awhile.