Multithreading is complex,but would AT-LEAST this be possible (for each AI or MP opp)

It's a mistake to think - if you do? - that each separate thread has the same power as the others. Four threads can't do double the work of two.

Most Intel chips (not familiar with AMD) also have the "Turbo" which increases voltage and speed for a given core if the others are not used.

 

True

 

32/64bit has nothing to do with multithreading. Multithreading is simply dependant on multiple cores. rF1 was threaded a little bit if you used the +fullproc option and rF2 is threaded even more. It just so happens that about the time the multi core CPUs went mainstream 64bit also went mainstream. But multithreading is nothing new.

It took games a long time to go 64bit because there was really no advantage to it and once you go 64bit you have two code bases to manage and it isn't practical to drop 32bit support. So most game devs avoid it if possible. rF2 only went 64bit to gain access to more memory. The main reason they needed more memory was because of the way DX9 handles texture allocation. On higher DX levels texture memory isn't duplicated in system RAM so the motivation to go 64bit isn't as high.

As for rF2 being more threaded, I don't know, it seems to load very even across all 4 cores on my machine. There is no way in hell the TGM model could be used on AI simply because it is threaded more. If rF2 loaded 2 cores to 100% and the other two were totally idle then yeah I could see more threading being helpful. But that just isn't the case from what I have seen.

 

There's a bit of misinformation starting to appear here so let me correct a couple things.

First of all, all your CPU's cores are capable of the same frequency as eachother (and is most often the case).

Secondly, rFactor 1 isn't a "lightly" multithreaded program just because you decide to use the "+fullproc" command line. The program is still a single threaded program. You're just deciding to split that workload between your threads if using the "+fullproc" command line option.

Thirdly, it's the same with rFactor 2. Just because you see it's workload being spread across your threads, doesn't mean anything other than just that. The program itself is still only a dual-threaded program as ISI has stated themselves (RF1= 1, RF2= 2).

Finally, a game is not programmed for a certain amount of cores. It's programmed for threads. Then it's the OS's task scheduler which decides which threads to use. The game goes by threads, not cores.

P.S. I advise some to read the OP; It's been stated that rF2's AI currently run fine, but I'm not talking about current AI. I'm talking about slowly starting to evolve the product, or at least give us the option (for testing/experimenting at our own risk with regards to game-performance) for AI with full player physics. However, that would be extremely demanding and "melt" our PCs and that's why I thought of the idea of each AI running in it's own thread since almost all CPUs are highly threaded nowadays and RF2 is currently not using anywhere close to our total CPU performance.

I was just thinking of some cool ideas as an inspiration to get into some more threaded use on RF2s side. Just ideas.

 

In that case : full AI with physics : it can be an idea to create pthreads that will be spread arround all core threads available on a particular system ...
But a pain in the ass ton code !!
Must modify main program to wait for pthreads ... It's huge rewrite of the main code.
This should be done since the begining of the coding process.
And afterall, do you think full physic for AI is really a benefit? When you drive do you care if the AI is in front of you because its behaviour is based on wrong physics? Will you feel more confident if its behaviour is based on real physics...

That's why ISI made simple physics for AI as it's enough, and you drive online with friends, here you got real physics calculated on each player computer. They focused on netcode, not full physics AI.

There's no point to code threaded AI for the benefit, it will melt every cpu arround.

And again, it's a pain in the ass to code threaded program!!!

Even BIG industrial programs are not threaded and I'm a sys engineer to say this!

 

gagipro, I appreciate the fact that you personally couldn't care less about the depth, as well as realism, of the vehicle dynamics belonging to the other cars (AI) on track with whom you're racing against.

I also appreciate the fact thst you think noone else cares about the realism of the other cars they are on the track with and driving against.

So thank you for your insight and opinions.


I know that threaded programming can be "a pain" from the research I've done on it. So was probably creating the rFactor 2 tyre model. So is going to school or work for some people. So are many things in life. If wether something is a "pain-in-the-ass" or not is your way of deciding wether something is worth doing, or at least worth considering, then I personally feel you may be in the minority.

Again though, thank you for your opinion on that.


By the way, TONS of industrial programs are highly multithreaded. It's a lot more simple than games for many types of industrial programs to use multiple threads. Try rendering a video, but first disable all your cores in your PCs BIOS except two, and also disable hyperthreading if you have it. Go render a video, then retry rendering it with all your cores, and hyperthreading, activated. Major, major difference. Same with 3D mark (mostly the CPU/physics tests), unzipping files, and so on and so on.

We have so much power on our CPUs leftover which RF2 isn't taking advantage of. The new consoles, I believe, are using 8 threads. Battlefield takes advantage of the more threads you have (you should see how smoother and better the framerates are on a 64 player server with a 6-core CPU VS a 4-core. The differences are startling). You should try playing Assetto Corsa against a field of A.I. with just two threads (I believe AC is natively a 4-threaded program, but I'm not 100% sure on that and the details).

 

Not the same, you cut in chunks a calculation that can be spreaded on multicores.
No realtime in your exemple Spinelli.
I usually decide to do things when there is a benefit to do it.
I know that AI are not realist but it's a huge work to make real behaviour AI, so much work that it can break what already works.

A lot if industrial programs are multithreaded, perhaps they don't do real time stuff or that you don't know anything on their inside code!

I will now unsubscribe from this thread

Good luck Spinelli

 

Actually +fullproc on rF1 threw the GFX driver thread and plugin API thread (which would include netcode) on separate cores. The OS can't simply "split" a single thread across multiple cores.

 

Far too much misinformation for new users to be reading. Again.

Thanks Noel for clarifying things for those who wish to learn about these kind of things, much appreciated for you to take the time on what seems to be an endless barrage of this.