Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: MP-Ryan on August 23, 2008, 03:46:48 am
-
Do the latest 3.6.10 builds automatically set themselves to use only a single processor core? I've noticed whenever I launch FS2 it is setting itself to only one processor.
-
They should do.
-
On quad core systems, FSO will set itself to only use core #2
-
They should do.
Ah, so it is intentional?
I just noticed it last night. I also noticed that if I set it to run on both cores I had no trouble, which is why I asked.
-
Yeah, it's intentional. There have been numerous reports of problems related to multiple cores so it was just decided to make the code handle it by default. It currently defaults to the second core in a multi-core system.
You can use the "ProcessorAffinity" setting to change it if you need to do so. It's a DWORD value, with 0 making it use all available cores, 1 making it use the first core, and 2 to make it use the second core (the default). Just be aware that the value is a bit-mask, so don't simply change it to just anything, make it one of those three numbers only.
-
Yeah, it's intentional. There have been numerous reports of problems related to multiple cores so it was just decided to make the code handle it by default. It currently defaults to the second core in a multi-core system.
You can use the "ProcessorAffinity" setting to change it if you need to do so. It's a DWORD value, with 0 making it use all available cores, 1 making it use the first core, and 2 to make it use the second core (the default). Just be aware that the value is a bit-mask, so don't simply change it to just anything, make it one of those three numbers only.
That seems to work.
Any way a feature like this could be added to the command line options, perhaps under game Speed or Troubleshooting?
-
Where do i change that setting?
Launcher or a windows setting?
-
Where do i change that setting?
Launcher or a windows setting?
Registry.
Go to Start - Run - type regedit.exe - press enter.
Go to HK Local Machine - Software - Voilition
New -> DWORD
Name it "ProcessorAffinity" (no quotes).
Right-click on the new key and select Modify... (NOT Modify Binary data). Change the value to zero and set it to hexidecimal. Click OK. Close Regedit.
---
See how much better a command line option would be? =)
-
Any way a feature like this could be added to the command line options, perhaps under game Speed or Troubleshooting?
Definitely not. How we are doing it now is the correct way to do it.
-
OK then.
For anyone else who wants both cores enabled, I'm attaching a registry file that contains only the appropriate key. Rename from .txt to .reg, then double-click to add it to the registry. Windows only, of course.
[attachment deleted by ninja]
-
I know someone will ask sooner or later so I might as well do it now.
Any way to setting the default to core 3 or 4? I assume you could still set it to 0 and then change it in task manager after it's running.
-
Ooops. We are maybe opening Pandora's Box.
In my system, (see my signature), FSOpen definitely ran slower on multiples cores. Before the "single-core" selection was added I even used imagecfg tool, (look for it in google), to force affinity in just one core.
Please, test deeply, and DON'T GIVE ANY GENERAL ADVICE ABOUT FREEING THE AFFINITY SELECTION.
-
Ooops. We are maybe opening Pandora's Box.
In my system, (see my signature), FSOpen definitely ran slower on multiples cores. Before the "single-core" selection was added I even used imagecfg tool, (look for it in google), to force affinity in just one core.
Please, test deeply, and DON'T GIVE ANY GENERAL ADVICE ABOUT FREEING THE AFFINITY SELECTION.
I wonder if its a difference between quad and dual cores?
My Core2 Duo E8400 (which is 3 GHz) runs it just fine using both cores, though the performance difference between using one or both is pretty much negligible.
-
My Core2Quad ran just fine with all 4 enabled so it's not that.
-
Any way to setting the default to core 3 or 4?
It's possible, but I'm not sure what values to tell you to use. Based on what you set you could end up on a virtual rather than a logical CPU, which could seriously kill performance for you. I only needed it to work properly for dual core systems (since it works in all cases then) so I didn't really try and figure out how the hell that affinity-setting system function actually works.
I will say that for the basic settings:
- 0 does nothing (the code on our side does nothing that is)
- 1 restricts it to CPU0
- 2 restricts it to CPU1
- 3 restricts it to CPU0+CPU1
Based on that you can maybe figure out how to get it on core 3 or 4 on your own. You can enter in bad values, but I don't believe that it will cause any damage or anything, the command should just fail and it would be the same as using a setting of 0.
Oh, and the function in question is called SetProcessAffinityMask(), if you want to google for it or look on MSDN to get more info on it.
-
I'll probably never have a need for it unless someone comes up with another file that needs password cracked. That was the only time I've ever needed to use set affinity.
-
This (http://gsaraiva.projects.pro.br/?p=139) and this (http://delphi.newswhat.com/geoxml/forumhistorythread?groupname=borland.public.delphi.language.basm&[email protected]) suggests that it's just a mask. So:
1 - First processor/core
2 - Second processor/core
4 - Third processor/core
8 - Fourth processor/core
16 - Fifth processor/core
...and so on, where 2^n is the nth processor or core. To use multiple ones you add the numbers:
ProcessorAffinity = 8+16 (Use fourth and fifth cores)
I couldn't find anything that stated what happens if you use the 'wrong' numbers. So use at your own risk.
-
I might just be a nugget here (in fact this is my first post) but because a previous job had me trying to explain this concept (in much futility) to countless people who wanted to know why their shiny new phenom/core2quad wasn't as fast as it "should be" i feel compelled to take part in this thread in spite of having no established credibility here.
that said... to anyone who has even considered toying with the program's multicore affinity in hopes of improving performance, listen up: just leave it, seriously, no touch! changing what cores it runs on in nearly any case will result in little more than mere placebo at best, but you're more likely to make performance suffer than anything.
multi-core processors offer little advantage to gaming overall, especially a game written in 1999 before such cpus were even on the market. why?
because:
-pc games rely more on graphics processors than cpus, frequently even if a game maxes your video card and your RAM it still won't be bogarting the cpu time
-what little benefit is to be seen with multicore processors is that you can restrict your game to the second core and the os and other apps will pretty much stick to the first core
-a game can potentially make effective use of multiple cores if they are programmed to do so, but unless someone here seriously overhauled the engine on a fundamental level (or i'm seriously misunderstanding something), fs2 is not one of those games
so unless you've committed one of your cores to encryption cracking, or you're testing your newtonian physics mod that you wrote to thread itself on a separate core, i hope i don't come across as pretentious because i doubt people without at least some practical knowledge wander into this part of the forum much but i would strongly suggest leaving your registry and your multicore as they are
that said, i think i've run my mouth enough for now, so, it's nice to meet you all :cool:
-
Sounds pretty much correct to me. :yes:
-
This is rubbish! Absolute rubbish! Multi-core CPUs are the wave of the future! Intel demoed an 80-core CPU running on an FPGA years ago (http://hardware.slashdot.org/article.pl?sid=06/09/26/1937237&from=rss) - even though it was running on an FPGA, it could run XP! It didn't run very fast, but because it was a prototype board all the signals had to go through a bunch of gates. Once they get a design that uses real transistors instead of gates it will be way faster.
These CPUs are coming out really soon. I even bet tomorrow they'll be announcing the Core 3 32-o (http://en.wikipedia.org/wiki/Intel_Core_3) with 32 cores. Only this time it won't be a prototype - oh no, it will be a monster 4 GHz, 32-core computing machine. Should be really easy to do once they get their 32 nanometer process up and running. With the power savings I bet it will run with less power than one of their 90 nanometer octo-cores (http://www.cpu-world.com/Cores/Smithfield.html).
The FS2SCP cannot ignore this trend. We need to be able to take advantage of these CPUs NOW, before it gets beaten out of the gate by all the other space simulator projects, open- and closed-source. I hear the Descent Rebirth (http://www.dxx-rebirth.de/) team has a huge update coming that will take Descent's ~15 year-old engine and make it look and run ten times better than anything currently on the market, or that will soon be on the market. And you know how they're going to do that? By taking advantage of multiple cores, and the special SSE5.1 instructions built into these upcoming Intel CPUs. Damn, I hear even Orbiter (http://orbit.medphys.ucl.ac.uk/) is adding space combat. It's going to be awesome.
We have to make the FS2 engine more parallelism (http://en.wikipedia.org/wiki/Parallel_computing) if we want to keep up. Our target hould be to get it running perfectly on one of these soon-to-be released Intel CPUs. I know your instinct is going to be to make use of that awesome feature that takes all 32 cores and reconfigures them into one giant core to rule them all (http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3382&p=13). But that's wrong! That's what all the other teams want you to try! What happens when you have that many instructions in flight at that kind of speed (we're talking terahertz here) is that you strangle even the best I/O bus money can buy. That's right, the FSB (http://en.wikipedia.org/wiki/Front_side_bus), HyperTransport (http://en.wikipedia.org/wiki/HyperTransport), even Intel's new QuickPath (http://en.wikipedia.org/wiki/Intel_QuickPath_Interconnect) can't handle the raw amount of data put out by a CPU in this mode. Sure, there are some narrow scientific uses nobody cares about (http://folding.stanford.edu/) that keep all the traffic on-die and require no access to the memory controller or the graphics controller, but FS2 is not one of those applications. That CPU is generating thousands of teraflops per second, and it needs to send those teraflops to the graphics card as fast as it can. The problem is that graphics cards have to process those teraflops really fast to put them on the screen, right? And ATi only just came out (http://www.dvhardware.net/article27907.html) with a video card that can only handle two teraflops per minute. So clearly it can't keep up with these Intel CPUs. The other teams know that, and they're already looking for another way to harness the power of these new CPUs.
Fortunately, I was recently fired by a team working on a very promising space project (http://kotaku.com/5032717/dark-horizon-on-the-horizon-for-september) which I'm not allowed to name. I know the method they're using to optimize to put more parallelisms in their code! The trick isn't to try and get all of the cores on the CPU doing the same thing at the same time to make it faster, because each core will just end up waiting its turn for the L2 cache (http://sharikou.blogspot.com/2007/09/intels-only-trick-was-cache.html), no matter how big it is. No, the trick here is like this: say you have a 32-core CPU. You load your executable into memory starting at address 0x00000000. Yeah, I know, that's really reserved kernel memory or something like that, but for the sake of argument let's pretend that the OS uses an addressing scheme that loads the executable at 0x00000000. Pretend that the OS realized I had this awesome idea and made all this space for me by throwing the kernel on the stack (http://en.wikipedia.org/wiki/Call_stack) (which usually starts at 0xFFFFFFFF and grows down). You know what I mean here.
So anyway, you have core 0 start executing at 0x00000000. Then you have core 1 start executing at 1/s, where s is the size (in the address space) of your program. Core 2 starts at 2/s, core 3 at 3/s, and so on and so forth. All of the code in the FS2 executable will be executed much faster. How much faster you ask? Try 32 times faster! That's right, we've finally found a way to get linear speedup out of multiple cores!
But how is this possible? Every computer science paper you've read, even the most optimistic marketing (http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543_5730~120403,00.html) you've seen have shown less than linear speedup as you add codes. What's the secret? The secret is the IOMMU (http://en.wikipedia.org/wiki/IOMMU), or I/O Memory Management Unit. It was initially developed because it would be useful for Virtualization. The problem is that even with these massively powerful processors, virtual reality is years away yet. At least two. So in the meantime, we've found another use for this really fast memory management device. When it is implemented on the same die as the CPU, it can be used to pass messages between all 32 cores. The device literally stands on its head (okay not literally, it would fall out of its socket) to pass just-in-time messages from one CPU to another, supplying it with information just as it needs it.
So, I realize I kind of rambled on a bit here, but this new technology gets me excited. In short, here's the steps I'm proposing the SCP team take:
1. Design an engine which dynamically takes different slices of the game code and passes it to idle CPUs as needed.
2. Hack together an IOMMU driver to make the performance of the above solution acceptable. The goal should be no less than linear CPU scaling as CPUs are added. I think the best we can hope for is 2xlinear, if we find a way to take advantage of reverse-hyperthreading (http://www.bit-tech.net/news/2006/04/17/amd_reverse_hyperthreading/).
3. Make a complete switch to ray-tracing because rasterized graphics do so poorly when you spread the load out over more processing cores (just look at the size of GT200, and how it's beat in some cases by the smaller RV770!).
4. Take advantage of the iSSE5.1 instructions, which are the most important part of what I just explained.
5. Beat the DXX-Rebirth team to market, because they're going to use all their CPU power to make sure their game has an awesome story and lots of plot twists.
-
Fine. You get on with that. Tell us when you're done. :p
-
This is rubbish! Absolute rubbish! Multi-core CPUs are the wave of the future! Intel demoed an 80-core CPU running on an FPGA years ago (http://hardware.slashdot.org/article.pl?sid=06/09/26/1937237&from=rss) - even though it was running on an FPGA, it could run XP! It didn't run very fast, but because it was a prototype board all the signals had to go through a bunch of gates. Once they get a design that uses real transistors instead of gates it will be way faster.
These CPUs are coming out really soon. I even bet tomorrow they'll be announcing the Core 3 32-o (http://en.wikipedia.org/wiki/Intel_Core_3) with 32 cores. Only this time it won't be a prototype - oh no, it will be a monster 4 GHz, 32-core computing machine. Should be really easy to do once they get their 32 nanometer process up and running. With the power savings I bet it will run with less power than one of their 90 nanometer octo-cores (http://www.cpu-world.com/Cores/Smithfield.html).
Somehow I don't think any decently priced consumer level computers are going to end up with that number of cores for quite a few years.
The FS2SCP cannot ignore this trend. We need to be able to take advantage of these CPUs NOW, before it gets beaten out of the gate by all the other space simulator projects, open- and closed-source.
Other space simulators?
I hear the Descent Rebirth (http://www.dxx-rebirth.de/) team has a huge update coming that will take Descent's ~15 year-old engine and make it look and run ten times better than anything currently on the market, or that will soon be on the market. And you know how they're going to do that? By taking advantage of multiple cores, and the special SSE5.1 instructions built into these upcoming Intel CPUs. Damn, I hear even Orbiter (http://orbit.medphys.ucl.ac.uk/) is adding space combat. It's going to be awesome.
As other people have said, graphics tend to improve due to better GPUs and extra instructions usually have very little effect on anything they aren't specifically aimed at.
We have to make the FS2 engine more parallelism (http://en.wikipedia.org/wiki/Parallel_computing) if we want to keep up.
The word you're looking for is multithreaded.
Our target hould be to get it running perfectly on one of these soon-to-be released Intel CPUs. I know your instinct is going to be to make use of that awesome feature that takes all 32 cores and reconfigures them into one giant core to rule them all (http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3382&p=13). But that's wrong! That's what all the other teams want you to try! What happens when you have that many instructions in flight at that kind of speed (we're talking terahertz here) is that you strangle even the best I/O bus money can buy. That's right, the FSB (http://en.wikipedia.org/wiki/Front_side_bus), HyperTransport (http://en.wikipedia.org/wiki/HyperTransport), even Intel's new QuickPath (http://en.wikipedia.org/wiki/Intel_QuickPath_Interconnect) can't handle the raw amount of data put out by a CPU in this mode.
I/O can never keep up with CPU speed, hence the need for multiprogramming. Also, do you feel like providing these soon-to-be released Intel CPUs for every coder?
Sure, there are some narrow scientific uses nobody cares about (http://folding.stanford.edu/) that keep all the traffic on-die and require no access to the memory controller or the graphics controller, but FS2 is not one of those applications. That CPU is generating thousands of teraflops per second, and it needs to send those teraflops to the graphics card as fast as it can. The problem is that graphics cards have to process those teraflops really fast to put them on the screen, right? And ATi only just came out (http://www.dvhardware.net/article27907.html) with a video card that can only handle two teraflops per minute. So clearly it can't keep up with these Intel CPUs. The other teams know that, and they're already looking for another way to harness the power of these new CPUs.
You do know that flops are a measure of floating point operations per second, right? Teraflops per second or per minute have no meaning.
Fortunately, I was recently fired by a team working on a very promising space project (http://kotaku.com/5032717/dark-horizon-on-the-horizon-for-september) which I'm not allowed to name.
Did you go on a tirade telling them to focus entirely on unreleased hardware too?
I know the method they're using to optimize to put more parallelisms in their code! The trick isn't to try and get all of the cores on the CPU doing the same thing at the same time to make it faster, because each core will just end up waiting its turn for the L2 cache (http://sharikou.blogspot.com/2007/09/intels-only-trick-was-cache.html), no matter how big it is. No, the trick here is like this: say you have a 32-core CPU. You load your executable into memory starting at address 0x00000000. Yeah, I know, that's really reserved kernel memory or something like that, but for the sake of argument let's pretend that the OS uses an addressing scheme that loads the executable at 0x00000000. Pretend that the OS realized I had this awesome idea and made all this space for me by throwing the kernel on the stack (http://en.wikipedia.org/wiki/Call_stack) (which usually starts at 0xFFFFFFFF and grows down). You know what I mean here.
You'd put the entire kernel on a user stack?
So anyway, you have core 0 start executing at 0x00000000. Then you have core 1 start executing at 1/s, where s is the size (in the address space) of your program. Core 2 starts at 2/s, core 3 at 3/s, and so on and so forth. All of the code in the FS2 executable will be executed much faster. How much faster you ask? Try 32 times faster! That's right, we've finally found a way to get linear speedup out of multiple cores!
That's great if your code executes completely linearly, once and no code depends on anything happening before it, which would be never. You may wish to note that if all the code in the executable were just run once, it would finish pretty quickly. Also, this would completely kill locality on the code segment creating that massive cache footprint you mentioned earlier.
But how is this possible? Every computer science paper you've read, even the most optimistic marketing (http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543_5730~120403,00.html) you've seen have shown less than linear speedup as you add codes. What's the secret? The secret is the IOMMU (http://en.wikipedia.org/wiki/IOMMU), or I/O Memory Management Unit.
That has nothing to do with CPU performance.
It was initially developed because it would be useful for Virtualization. The problem is that even with these massively powerful processors, virtual reality is years away yet.
Virtualisation has nothing at all to do with virtual reality.
At least two. So in the meantime, we've found another use for this really fast memory management device. When it is implemented on the same die as the CPU, it can be used to pass messages between all 32 cores. The device literally stands on its head (okay not literally, it would fall out of its socket) to pass just-in-time messages from one CPU to another, supplying it with information just as it needs it.
Why would an MMU pass messages between CPUs? The IOMMU has nothing to do with the CPU.
So, I realize I kind of rambled on a bit here, but this new technology gets me excited. In short, here's the steps I'm proposing the SCP team take:
So excited that you didn't understand any of what it does?
1. Design an engine which dynamically takes different slices of the game code and passes it to idle CPUs as needed.
Adding huge overheads (in addition to all the other overheads inherent to multithreading).
2. Hack together an IOMMU driver to make the performance of the above solution acceptable. The goal should be no less than linear CPU scaling as CPUs are added. I think the best we can hope for is 2xlinear, if we find a way to take advantage of reverse-hyperthreading (http://www.bit-tech.net/news/2006/04/17/amd_reverse_hyperthreading/).
Linear scaling with additional CPUs is not going to happen and has nothing to do with IOMMUs.
3. Make a complete switch to ray-tracing because rasterized graphics do so poorly when you spread the load out over more processing cores (just look at the size of GT200, and how it's beat in some cases by the smaller RV770!).
Wha?
4. Take advantage of the iSSE5.1 instructions, which are the most important part of what I just explained.
What SSE5.1 instructions and what might they do?
5. Beat the DXX-Rebirth team to market, because they're going to use all their CPU power to make sure their game has an awesome story and lots of plot twists.
Increasing CPU power does not improve stories or plot twists.
-
I might just be a nugget here (in fact this is my first post) but because a previous job had me trying to explain this concept (in much futility) to countless people who wanted to know why their shiny new phenom/core2quad wasn't as fast as it "should be" i feel compelled to take part in this thread in spite of having no established credibility here.
that said... to anyone who has even considered toying with the program's multicore affinity in hopes of improving performance, listen up: just leave it, seriously, no touch! changing what cores it runs on in nearly any case will result in little more than mere placebo at best, but you're more likely to make performance suffer than anything.
multi-core processors offer little advantage to gaming overall, especially a game written in 1999 before such cpus were even on the market. why?
because:
-pc games rely more on graphics processors than cpus, frequently even if a game maxes your video card and your RAM it still won't be bogarting the cpu time
-what little benefit is to be seen with multicore processors is that you can restrict your game to the second core and the os and other apps will pretty much stick to the first core
-a game can potentially make effective use of multiple cores if they are programmed to do so, but unless someone here seriously overhauled the engine on a fundamental level (or i'm seriously misunderstanding something), fs2 is not one of those games
so unless you've committed one of your cores to encryption cracking, or you're testing your newtonian physics mod that you wrote to thread itself on a separate core, i hope i don't come across as pretentious because i doubt people without at least some practical knowledge wander into this part of the forum much but i would strongly suggest leaving your registry and your multicore as they are
that said, i think i've run my mouth enough for now, so, it's nice to meet you all :cool:
While I pretty much agree with you, some games, such as Sins of a Solar Empire, are far more CPU intensive than GPU intensive.
-
Make a complete switch to ray-tracing because rasterized graphics do so poorly when you spread the load out over more processing cores (just look at the size of GT200, and how it's beat in some cases by the smaller RV770!)
There are 5 million things wrong with your post, of which many have already been pointed out, but I'm a graphics-crazy guy, and I want to point this out:
Ray tracing is not currently a viable method of rendering, and will not be for many years to come. This isn't because we can't do raytracing in realtime, its simply because a rasterization approach is going to look a whole heck of a lot prettier for a very long time. Saying that rasterized graphics will preform worse then equally good-looking raytracing graphics is like saying that C++ code will run slower then Java code.
Ray-tracing only becomes beneficial when you are dealing with global illumination, soft shadows, and reflections/refractions. People can go ahead and scream that real-time raytracing is the wave of the future, but people also said we were all going to die when the LHC was turned on.
-
Okay, saying things like
5. Beat the DXX-Rebirth team to market, because they're going to use all their CPU power to make sure their game has an awesome story and lots of plot twists.
just makes me think the whole thing is somehow sarcasm.
-
Fortunately, I was recently fired by a team working on a very promising space project (http://kotaku.com/5032717/dark-horizon-on-the-horizon-for-september) which I'm not allowed to name.
what i find hilarious is the hypocritical nature of this sentence.
-
This is rubbish! Absolute rubbish! Multi-core CPUs are the wave of the future! <snip...>
These CPUs are coming out really soon. I even bet tomorrow they'll be announcing the <snip...>
The FS2SCP cannot ignore this trend. We need to be able to take advantage of these CPUs NOW<snip...>
We have to make the FS2 engine more <snip...>
Fortunately, I was recently fired by a team <snip...>
So, I realize I kind of rambled on a bit here, but this new technology gets me excited. In short, here's the steps I'm proposing the SCP team take:
1. Design an engine which dynamically takes different slices of the game code and passes it to idle CPUs as needed.
2. Hack together an IOMMU driver to make the performance of the above solution acceptable. The goal should be no less than linear CPU scaling as CPUs are added. I think the best we can hope for is 2xlinear, if we find a way to take advantage of reverse-hyperthreading (http://www.bit-tech.net/news/2006/04/17/amd_reverse_hyperthreading/).
3. Make a complete switch to ray-tracing because rasterized graphics do so poorly when you spread the load out over more processing cores (just look at the size of GT200, and how it's beat in some cases by the smaller RV770!).
4. Take advantage of the iSSE5.1 instructions, which are the most important part of what I just explained.
5. Beat the DXX-Rebirth team to market, because they're going to use all their CPU power to make sure their game has an awesome story and lots of plot twists.
Wow. Just wow. Well, just about the whole post is devoid of reasonable technical merit and accuracy.
The need to multithread new applications is undeniable, but the ability to cram new threads into an existing codebase and not screw the pooch is not something that is reasonable. To do a good multi-threaded game engine requires the choices to be made up front so the data structures can be organized in a fashion that doesn't require exotic constructs like virtual software IOMMUs. Proper data structure design is far more important than the code itself since almost all the less than linear increase per added core performance is due to data contention.
-
It's sarcasm. DXX Rebirth? Plot twists?
:lol:
-
valve pulled it off with half life, but then again... they completely rewrote it to do it =p and they threw in an x64 single player version too.
while scp has indeed made fs2 a work of art, it still doesn't have that much of a load on resources. Look at some of the models people have released. Not ridiculous on poly count yet still things im proud to play with... Hell the media VP's are the best thing since sliced bread. I think the focus on features out weighs multi-threading by a long shot. Would it be nice to see? sure but it's not necessary. Just my two cents...
-
yup, FS2 on one core leaves the other 3 free for music or torrents or rendering or whatever else i feel like doing :-P
-
valve pulled it off with half life, but then again... they completely rewrote it to do it =p and they threw in an x64 single player version too.
while scp has indeed made fs2 a work of art, it still doesn't have that much of a load on resources. Look at some of the models people have released. Not ridiculous on poly count yet still things im proud to play with... Hell the media VP's are the best thing since sliced bread. I think the focus on features out weighs multi-threading by a long shot. Would it be nice to see? sure but it's not necessary. Just my two cents...
I'm sure race conditions and deadlocks can be simulated in one thread if you ask nicely enough.
-
If I may say something, it is simply this. Please don't feed the trolls. The only correct thing that guy said was that multi-core CPUs are the wave of the future. That is correct. THE FUTURE. The game we work on is a game of the past. If he is too foolish to grasp this, we shouldn't bother responding to him.
-
Wow, he just wasted about an hour of his life. Why in the world would you use all that power to run 1 game? That's stupid, especially when the game itself is already running at full speed? I thought the purpose of having "multicores" was to "multitask" better, right?
Besides, the less processing power a program requires, the more that is available to other programs, which means MORE multitasking ;)
MikeRoz, please read up on what multiple cores are all about, otherwise shut up! If you want to run FS2 with the most processing power, then buy a single core processor and overclock it like crazy, around the 5GHz mark; then run FS2 on it. Otherwise, the guys here are doing an amazing job on this project and I couldn't be more proud of them :)
P.S: I know that the developers here are gonna come out with something that's gonna make FS2 even better, so I'm gonna have to increase my capacity for happiness ;D
-
Wow, didn't this thread die back in September? I guess I have no choice but to respond.
Wow, he just wasted about an hour of his life. Why in the world would you use all that power to run 1 game? That's stupid, especially when the game itself is already running at full speed? I thought the purpose of having "multicores" was to "multitask" better, right?
Besides, the less processing power a program requires, the more that is available to other programs, which means MORE multitasking ;)
MikeRoz, please read up on what multiple cores are all about, otherwise shut up! If you want to run FS2 with the most processing power, then buy a single core processor and overclock it like crazy, around the 5GHz mark; then run FS2 on it. Otherwise, the guys here are doing an amazing job on this project and I couldn't be more proud of them :)
P.S: I know that the developers here are gonna come out with something that's gonna make FS2 even better, so I'm gonna have to increase my capacity for happiness ;D
Yeah but that's the point. Intel's latest chip offers eight logical cores, and future chips (http://en.wikipedia.org/wiki/Itanium#Itanium_2_processors:_2002.E2.80.93present) are sure to offer even more performance (http://en.wikipedia.org/wiki/Phenom_(processor)). Unless you participate in Origami folding competitions (http://folding.stanford.edu), that extra power is just going to be sitting there, wasted. Yet we all know a simulation like FS2 needs all the processing power it can get, and that can easily be split off into multiple cores.
Just look at all the things going on in FS2. I mean, it's a feat that Volition was able to make it run on the computers of 1998 and 1999. Let's just start with a single fighter going flying through an "empty" map. You've got all the systems of the fighter that have to be simulated: weapons, propulsion, life support, shields, sensors, communications, etc. Though they all have to work together to some extent, their tasks are largely independent, making them the perfect candidates to be split off into threads.
And then there's the supposedly empty map. Should be easy to simulate, right? Wrong! Even outer space isn't a perfect vacuum (http://en.wikipedia.org/wiki/Vaccuum#Outer_space). There are several hydrogen atoms per centimeter. This is zillions of atoms, flying every which way, interacting with each other, bouncing off your ship, at every given moment. Some day we may be able to assign a thread to each so that their processing is not all crammed into one line of execution, but we may not quite be there yet. In the meantime, there is still plenty the team can do with multiple cores. Like explaining where the Shivans came from.
Wow. Just wow. Well, just about the whole post is devoid of reasonable technical merit and accuracy.
The need to multithread new applications is undeniable, but the ability to cram new threads into an existing codebase and not screw the pooch is not something that is reasonable. To do a good multi-threaded game engine requires the choices to be made up front so the data structures can be organized in a fashion that doesn't require exotic constructs like virtual software IOMMUs. Proper data structure design is far more important than the code itself since almost all the less than linear increase per added core performance is due to data contention.
Alright, so I admit I was a bit hasty by introducing my whole start-n-threads-of-FS2-by-starting-execution-of-thread-x-at-position-x/n-in-the-code idea. I actually tried this by defining a bunch of function pointers to point to the desired areas of the code, and then spawning a pthread with each function pointer. To even my surprise, the game ran the first time. It even ran slightly faster. To my horror, instead of blowing up Capella in my playthrough of the retail campaign, the Shivan AI suddenly became transfixed by one random point in space and began to congregate all their ships there. And by all, I mean all. The area soon collapsed into a supermassive black hole into which all the surrounding systems were sucked. It took forever, less due to performance issues and more due to relativistic effects.
Needless to say, there is a small but crippling concurency bug in the AI that prevents this method of multithreading that I have no interest in fixing. There's no time, not if we want to beat the GL-117 (http://en.wikipedia.org/wiki/GL-117) team's next-generation effort to market. But don't worry, I've got a great idea they'll never see coming. You see, they only plan to take advantage of the processing power one machine has to offer. Which would be fine, if this were 1997. You see, however, multithreadedness is in the future, and distributed computing (http://en.wikipedia.org/wiki/Distributed_computing) is on the horizon. If we get there first, the world, as they say, will be ours.
My friends, I give you FSOS. That's FreeSpaceOperatingSystem. With hardware IOMMUs (not the clumsy software things you brought up earlier, Enki) even closer to becoming mainstream, virtualizing an OS is starting to carry less and less of a penalty. If we make FreeSpace into an OS, we can harness this advantage!
To explain, an IOMMU (http://en.wikipedia.org/wiki/Iommu) is a device that arbitrates memory and peripherals so that each of any multiple OSes on a computer thinks it has complete and direct control of the hardware, at no performance penalty. In the future, we may harness this to run multiple copies of FSOS at the same time, all with little to no performance penalty, but we should first focus on getting one copy of FSOS stable working on multiple cores.
"But no!" enki is fuming, "You still haven't solved the problem of data contention!"
Did you really think I'd type all this without figuring out a solution to that too? The answer is simple. We reverse-engineer and use GoogleFS (http://en.wikipedia.org/wiki/GoogleFS). To a CPU, the hard disk is slow, and even its RAM is slow. But the Internet is fast! Just look at how fast Google's servers get results to your computer. This is because they use a file system that is designed from the ground up for redundancy, distributibility, and to be used concurrently by thousands of clients.
Of course, this will have the unfortunate side effect of requiring that the first few FSOS users have a cluster of GoogleFS machines attached to a local network to act as their filesystem. The good news is that subsequent users can use this space as quickly as though it were part of the cache on their CPU.
yup, FS2 on one core leaves the other 3 free for music or torrents or rendering or whatever else i feel like doing :-P
That is the beauty of FSOS :) Once we reach critical mass (I define that here as one thread per every four hydrogen atoms in free space), you will have access to a game world so vast and dynamic, that you can take care of all your game needs inside the virtual world. Since it's the computers of the future that we're simulating here, any task you undertake on a simulated computer in FSOS would complete in a fraction of the time it would take to complete on your silly 21st century machine.
To summarize:
1. FreeSpace as a simulation is highly constricted by CPU power and lack of parallelism; just look at all the underlying details abstracted away.
2. Simulating the game world on a more fundamental level will lead to more interesting stories.
3. Since AMD utterly failed (http://www.theinquirer.net/en/inquirer/news/2006/07/10/reverse-hyperthreading-does-not-exist) at it, we are stuck having to implement reverse-hyperthreading, and as a software library at that.
4. GPUs can be used to simulate drawing implements in the virutal world, since they're so good at rendering things.
5. I would love to see how sound fares in the engine when we transition to this more realistic model.
-
You've got all the systems of the fighter that have to be simulated: weapons, propulsion, life support, shields, sensors, communications, etc. Though they all have to work together to some extent, their tasks are largely independent, making them the perfect candidates to be split off into threads.
Okay, now I get it. You had me going for a while.
(In case you're not getting it, guys, he's kidding around.)
-
We should Totaly Take Advantage of that!!!!
I mean.. That would make fs2 better then fs3!!!!11
it would be like so cool with paralism and stuff!
-
Oh yeah, I kinda figured he was kidding around when he talked about DXX-Rebirth ;) But it's fun counter-arguing his pointless points :D
Yet we all know a simulation like FS2 needs all the processing power it can get, and that can easily be split off into multiple cores.
Um no, it doesn't need all the processing power it can get because it is already running at full speed. And no, it cannot be easily split off into multiple cores. But if you know how, then please do it for us. Heck, I'll even donate some money if you can get a major improvement in performance by allowing the game to use multiple cores. Otherwise, there's no point in enabling multiple cores if the performance improvement is minor. Besides, the less my CPU works, the longer it'll last, and less heat produced by the processor ;)
it's a feat that Volition was able to make it run on the computers of 1998 and 1999
Um, the game only requires like 200Mhz with a 3D card, and I had a 400MHz computer with a Nvidia Riva 128ZX in 1997. So it ain't no feat, and it is especially no feat to run that game on a modern 2008 computer, without the modifications of course ;) Quake 3, now that's a game that was developed way ahead of its time.
There are several hydrogen atoms per centimeter. This is zillions of atoms, flying every which way, interacting with each other, bouncing off your ship, at every given moment.
Um, why would we bother calculating all of that if we cannot see or feel it? Not even you know the effect of random particles on a ship in space. But if you wanna find out, Battlestar Galactica is selling all their props, including a Viper Mark II, though you'll have to make it space ready :lol:
In the meantime, there is still plenty the team can do with multiple cores. Like explaining where the Shivans came from.
What do multiple cores have to do with Shivan origin?
If you're that crazy in making all the things you said happen, then do it yourself. Then show it to us. The game better be in fully working condition and as interactive as Freespace 2 to get the acknowledgement of everyone here. Otherwise, you're just talk. You can't walk the walk. :drevil:
-
Oh, come on, don't feed the (uniquely awesome) troll.
-
Actually, i read if you had 10 dual core centrino's hooked up via a GNDN coudit,
plugged your satilite dish into the tv card of your pc but reversed the polarity of the LNB,
all while watching Tron you could....
-
If I may say something, it is simply this. Please don't feed the trolls. The only correct thing that guy said was that multi-core CPUs are the wave of the future. That is correct. THE FUTURE. The game we work on is a game of the past. If he is too foolish to grasp this, we shouldn't bother responding to him.
Who wants to be stuck in the past?
-
Actually, i read if you had 10 dual core centrino's hooked up via a GNDN coudit,
plugged your satilite dish into the tv card of your pc but reversed the polarity of the LNB,
all while watching Tron you could....
You would trigger a resonance cascade, that's what.
More on-topic: He's trolling, but at least in a very original and entertaining way, so keep it coming.
-
I concur.
-
I never said anything about being stuck in the past. Nevertheless, the game engine with which we work simply is too old to take advantage of multiple CPUs/multiple cores directly. Processor drivers that balance load can assist with this, but making the engine, especially a game engine this age, multi-threaded would be too much work for far too little gain. If we want multi-threading, then we'll just have to wait for the Ferrium project or whatever has succeeded it as an attempt to write a new game engine we can use, assuming there were any plans to multi-thread a successor game engine in the first place.
-
IBX (Cache) generation would be useful to have multi-threaded. It seems like it would be embarrassingly parallel and really help out a lot of people. It took like 5 or 10 minutes to generate them all for the new mediavp models using -pofspew, and that's on a 6 month old pc.
-
Ok, can't argue with that one. Definitely could be useful.
-
Modders should be shipping IBX files with their ships, and IBX generation should be implemented into PCS2 so that it exports the IBX data in the POF file as a POF chunk. For that particular problem, it would reduce the generation time to basically nil, whereas shifting it to multithreaded wouldn't really help people who would be hit hardest by it (people with old computers).
My comment was more of a general one directed at the mentality that seems to pervade this place. When you're rejecting reasonable points on the basis that an engine is too old, you should be considering what you're going to do about the engine being too old. One of the reasons listed for not implementing my last batch of code was that it had never been done before, so the engine wasn't designed for it, and the engine was too fragile. Furthermore, there's been multiple comments made about how unreliable the engine is in general, plus the general hardcoded nature of everything, and overall there's this general opinion that if you change too much, something, somewhere, is going to get screwed up and that will cause more bugs in mantis. It's like the boogeyman, except with code.
The only way to fundamentally change all of these complaints is to make some serious change. And some serious change is not possible unless you decide to break backwards compatibility, or risk breaking backwards compatibility, in order to make something better. That is why I refer to it as being stuck in the past. At some point, you have to let go and move on for the greater good, as a natural cycle of life. You can't have your cake and eat it too.
Here, the obvious solution is to make a new game engine. That opens up the possibility for optimizing the graphics code, implementing a proper physics engine that can be upgraded as time goes on, implementing a more 'loose' AI system that can be upgraded without breaking all prior missions, designing things to be run on a multicore processor, and so on and so forth. Then you go from talking about hacking the HUD so you can put better gauges in to talking about GMod for Freespace 2. Instead of Newtonian physics being the next thing, the people developing the physics engine release an update and you can have solar sails with realistic cloth physics.
The amount of work required to do such a thing would be considerable, but if you did it right, you would have something that would still have FS2 compatibility in mind but have the ability to be upgraded with other improvements as time went on. You could plan for feature requests instead of figuring out some clever workaround regarding the code that's already there.
The way things are going, I just don't see a critical change in the way that FS2Open works for a long long time. It will be upgrade after upgrade, but things will get harder and harder to implement as the restrictive nature of the code causes people to implement things in different, non-uniform ways because there is no good way to implement them, without ripping out a large portion of the code, which would have a significant change of introducing bugs and breaking backwards compatibility.
And just for the sake of stating it, I make a pretty ****ty programmer for what Goober and taylor want. I prefer to see people innovating and making things better in general, rather than dotting every 'i' and crossing every 't'. So if that's your thing, by all means, do forget about multicore support and focus on fixing every single bug in mantis. If you find the prospect of being able to create your own game engine from scratch and design it to support things you never dreamt of seeing in Freespace 2, then you might want to pay more serious attention to how you can leverage new technologies to this community's benefit.
That's my $0.02
-
What you're describing would essentially be writnig a new engine from scratch. There's nothing wrong with that, but you're looking at a multi-year project.
Anyway, mods/campaigns are still years behind the SCP in terms of using the full potential of the engine in its current state. New features are still implemented faster than mods can keep up with. As long as this is the case, I prefer the current policy of the SCP to fix as many bugs as humanly possbile to get a rock-stable engine. This, of course, is an opiniion from a modders perspective, and not a coders perspective.
-
You could try to finish up Ferrium, Coolmon. Was that project abandoned?
-
I thought some of the more popular games used an open source 3d engine? (my brain isn't working atm so i cant remember titles) But i swear something in my mind is screaming that i read one of the major 3d engines being open source
-
WMC, I have nothing against making things better, but there comes a point in time when you need to stop the line, so to speak, and fix your problems. The codebase currently has quite a few bugs, multiplayer has been plagued with problems making it almost useless for years, GLSL has all but completely broken the graphics on OS X, and you want to keep cramming more features into the system? I'm sorry but that just can't happen sometimes. It's like painting a house without scraping off the old paint first, if you keep doing that it's going to start falling off the siding from its own weight because the foundation (the old paint) can't support it anymore. At least by taking care of all the bugs and focusing a significant portion of coding time on cleaning up the codebase, it makes it easier down the line to add those new features. Sometimes it just needs to be done. I'm sorry if you don't agree, but you saw the state of the codebase when no one was fixing bugs and everyone was just committing feature after somewhat broken feature. Mantis bugs have been going down, even with all the new bugs being discovered by the testing builds, even some old ones have been ironed out recently.
As far as building IBX generation into PCS2, I'm pretty sure there was a reason we let the FS2 engine do that and not a separate program, although I can't exactly remember what it was. I don't know how having PCS2 generate it would make it go any faster than FS2 can do it, they both have access to the same data.
Also Vertigo, this _is_ an open source 3d engine. It's just not a free as in freedom license. But there are several other free 3d engines, most of them seemed to be geared towards FPS gaming, at least that's all I've seen done with them so far. Ogre is one, and then there's the Cube engine. Couple others as well but I can't remember them all off the top of my head.
-
As far as building IBX generation into PCS2, I'm pretty sure there was a reason we let the FS2 engine do that and not a separate program, although I can't exactly remember what it was. I don't know how having PCS2 generate it would make it go any faster than FS2 can do it, they both have access to the same data.
Kazan wasn't around and he, last asked, doesn't want to take the time to take the time to implement the IBX generation code into PCS2, nor does anyone else.
Having PCS2 generate it wouldn't make it go any faster than FS2...I didn't say it would, either. It could be twice as slow, too. But you act like people running -pofspew is a big enough deal to multithread it; they shouldn't be doing that in Freespace 2 if you can save IBX data in POF files. It should be done automatically in PCS2 when the geometry is converted to the POF, and loaded and saved with the rest of the POF data, so that the end users aren't required to be bothered with POFSpew. Granted, there's still reasons to test POF files, but I can't see much reason for that to be a frequent enough occurrence to spend a lot of time on optimizing it.
WMC, I have nothing against making things better, but there comes a point in time when you need to stop the line, so to speak, and fix your problems...
I don't know how to respond well to an ad hominem (however valid or invalid it may be) when it's in lieu of actually understanding what I said. General Battuta and Vertigo7 seem to get my point; you didn't.
I am extremely hesitant to work on the SCP for the concerns I expressed below. Communication on the team is complete crap; Goober scheduled a code freeze in the middle of the only free time I had this last summer. I've expressed this concern time and time again and there's been no change made. In fact, as near as I can tell, the majority of communication happens via PM or IM at this point.
I have no wish or desire to be made into a volunteer slave. I've worked, in some form, on the project for about 5 years. It's outlived its usefulness to me, personally, and I don't see the project as going in the direction for some 'higher good' right now. It's a game. It's not helping starving children in Africa. Its usefulness is measured by how entertaining it is, and how many people it entertains.
So if your claim is that I have some duty to sit around and bugfix all day, then, no. I don't want to spend the rest of my life redoing what other people have already done. If the existing game engine isn't capable of taking advantage of other people's work, if it's written in such a form that obstructs innovation more often than not, then the time I or anyone else spends working on it is suffering reduced leverage. At some point, the amount of time lost due to working around the existing constraints will equal the amount of time that could be used to write a new game engine with the same general properties as the Freespace 2 engine. It's impossible to measure that time, but I do think it can be said to exist. There's also a lot of capabilities that you lose out on in using the old engine, because you MUST maintain backwards compatibility, you MUST support the old files, you can't rewrite everything all at once, and so on and so forth.
So my personal opinion is not fixing bugs is dumb. My personal opinion is that good design leads to less bugs. Or rather, good design for the intended use leads to less bugs. The present engine had time constraints and assumed technology constraints with it. Those constraints may or may not exist now, and it's possible to take the time to question those constraints. Building a simple game engine doesn't take a whole lot of time. If it's done right, you can make little games that people can play and draw an audience for the engine. The fact that it's a new game engine has additional draw.
But if you want my own personal reason for why I'm not going to be bugfixing anytime soon - I don't enjoy it, and I absolutely disagree with the direction this project is headed, both in what I've detailed here, and in the attitude I've seen in spending $300 of community money on a toy, random forum pranks that more often than not end in forum crashes and errors, absolutely no inclination to listen to anything anybody else says without a considerable amount of condescension, banning community members because they ask the wrong question, and so on and so forth. No one act that's particularly horrible, but this is not an attitude or an environment that I can support in good conscience. Arguing hasn't changed anything. So I've done my own thing, done my best to make it work, and I'm pretty satisfied how that turned out. I've seen far less bugs flashing across mantis that had anything to do with them than I've ever seen, and I got far more implemented and repaired in the couple of months that I was coding full-bore than any other time.
I would prefer to work in a community where people try to find answers to problems and feature requests and there's enough manpower that there is time to innovate. I'd rather see that there are enough good ideas floating around and the environment is conductive enough that people can find a balance between preventative measures and enabling systems. I see some kind of mutual cooperation as being a necessity in such an environment, because everyone, including the lowliest bug tester, is giving up some kind of time for participation in the project. If you aren't paying them, you can't expect them to want to work for you, so some kind of individual expression or payback is necessary to make them want to participate. Or if you want to be less self-centered about it, you are obligated to do something for those other people in order to make it worth their time to participate, or you are guilty of unfairly exploiting them.
I don't know if such a place exists, but I do see a significant deviation from that vision and here. Sadly, I seem to be the only one who sees it, so all I can do is express my opinion and wait and see if my hypotheses is correct. It is possible that 3 or 4 people will come in and renovate the old engine to be fully functional and up-to-date, but I think it's extremely unlike. On the other hand, I think it's extremely unlikely that anybody in the community will have the desire, drive, time, and skills necessary to undertake such a project. I've expressed my opinion but I don't expect other people to necessarily agree and I'm certainly not planning on undertaking it myself. At this point I plan to stick around in a sort of advisory role if anybody has any further questions or problems that I'm needed to answer, but other than that, my coding days are over. I've given & sacrificed much for this project, and it's time for me to move on and let this project go this own separate direction so I can get on with the rest of my life.
Much more interesting post than I expected to write. :) [/soapbox]
-
I was only addressing the last portion of your previous post, not the post in its entirety. You're right, hitting so many walls due to the constraints of the engine can be frustrating, but I think the majority of the coders still has a lot of miles left on it, and it's still worth the time investment to maintain it instead of switching to a new, from-scratch system. Until the rest of the developers feel otherwise, I can't expect it to change. As for my statement being ad hominem, I guess I should have mentioned this article (http://community.ative.dk/blogs/ative/archive/2007/01/29/The-Waste-of-Defects-_2D00_-Bugs-are-Stop_2D00_the_2D00_Line-Issues.aspx). I'm not even going to pretend I have a lot of experience with agile development and other modern software engineering philosophies, but I am familiar with many of their concepts. That article got me thinking recently and reinforced my mindset that the current bugfix period is the right course of action and was long overdue. I don't expect any coder to do anything, what you spend your time on is your choice, but what I would appreciate is at least all serious bugs currently assigned to a coder to either be addressed or marked for resolution at a later date. I want to see the bugcount go down every release instead of up and start having a shorter release cycle. As much as I'd like to resolve every bug though, I know this isn't likely right now, but I think baby steps towards that direction can't hurt.