Multicore support

Foxhound

Famous
Joined
May 2, 2008
Messages
461
So I understood that TF2 only runs on one core, so Duo and Quad users don't see any benefit really. I was told about a command that lets you use multiple cores which gives the game a big boost but it can sometimes be unstable, crashing the game.

The command is "mat_queue_mode 2"

I've tried it a couple times. Sometimes I see a boost in performance, other times it's crazy laggy. Both will lead to an inevitable crash though. Has anyone else tried this?
 
yea i've tried this too, theres a reason why its not officially supported, it makes the game very unstable. Its too bad too, when I tried using it I was getting over 300 FPS consistently
 
I just bought new comp parts and now i have a core 2 duo 3.00ghz, it seems to run smoother with all my new parts, but not MAJOR differences
 
It doesn't support multi core, although the new Core 2 Duo line has a more efficient and faster single core then my old processor :P

Either way, what I did was bind mat_queue_mode 2 to f6 and mat_queue_mode -1 to f7, which allowed me to switch between the two at whim. If I found it to not be very beneficial, I would turn it off. If I dropped using single core, I would turn it on. I would also occasionally refresh it by playing in mat queue -1 for about 15 minutes. Never crashed :D
 
Nice idea AWP, I didnt know if the command was 1 or -1 to go back to a single core.

I did hear some news that Valve has been testing out multicore functionality and they found a more stable method which will, they say, most likely be made public (and set to default) with the release of Left 4 Dead. The game will support it, which, one would assume means it will apply to all the other source engine games.
 
I think the Source Engine uses multi-cores primarily to handle the particle effects; Pyro flames and the sparkly Teleporter trails. Could be wrong though. :)

There's also a few other variables you have to edit alongside with m_q_m 2 to make it a bit more stable, all related to particle_threads or something.
 
Hardhat is correct, the current version of Source uses a threaded particle system by default (r_threaded_particles 1). There are a handful of commands you can use to potentially improve performance, but they may also expose you to more bugs:

r_threaded_renderables 1
mat_queue_mode 2
host_thread_mode 1 (mostly useful for single-player games)
snd_mix_async 1 (causes some problems with sounds for me)

And a few more I cannot remember off the top of my head. The latter two are the only ones I have actually seen anyone from Valve endorse:

There are two cvars you can test for multicore support currently:

host_threadmode 1
snd_mix_async 1

In general, changing various other thread-related settings will just expose you to bugs and may not increase performance. I wouldn't recommend tweaking any of the other cvars mentioned in this forum thread.

The two I've mentioned above both shipped in the xbox 360 version and are fairly well tested, but still need a bit more testing on the PC platform before we enable them by default on multicore PCs.

host_threadmode allows server simulation to happen in parallel with some of the rendering. It is fine to set this to 1 in general, but it will only provide performance boosts in games where your machine is running both the client and the server (ep2 & portal for example, or tf2 if you are hosting the game but not if you are connected to an internet server).

snd_mix_async 1 will use multicore CPUs to run the most of the sound engine in parallel with the renderer.

Various parts of the particle, I/O and networking systems are already using multicore CPUs to improve performance. There are no settings to change for that behavior.
He made a typo, it is actually host_thread_mode.

http://forums.steampowered.com/forums/showpost.php?p=6953418&postcount=15
 
Last edited:
Maybe someday they'll add stable multicore support. My quadcore would be better with it ;D
 
Thanks Morbo.

So if I understand correctly, Valve is only really endorsing server type commands. Nothing really on the client end that is really stable yet?
I'll give thread_mode a try on Ep 2 and see what happens. mat_queue_mode has only lead to heartache for me so far.

And Gooda, you are more or less correct. They don't utilize more than one core, but have a few cvar commands in the works that could potentially remedy that. I'd really like to see some quad-core support in more things in the near future. So far I feel like I'm wasting cores for the most part.

Should be interesting as the year goes on.
 
I have a AMD 5600 X2 dual core processor overclocked to 3.01Ghz and the lastest dual core optimizer when i use "mat_queue_mode 2" i get a huge increase of fps and i dont lagg .. i used to lagg and crash but if you have a AMD processor go to the amd site and download the latest dual core optimizer .. it fixed it for me but if you have a realy bad GPU then i wouldnt bother .. you might just see 1-2 fps gain .. i have a fairly powerfull gpu (ATI 4850 oc 675/1100) so using only 1 core on my cpu realy holds it back

2nd post ive made xD

~Focus
 
I forgot about this one:
Mike Durand (originally posted on hlcoders mail list)

We default to taking advantage of no more than three threads due to some problems that we believe to be due to cache issues with current quad-core processors. You can override this limitation by specifying '-threads 4' on the command line if you like. '-threads 8' should work with this build as well when eight core processors become available.

-Mike
 
I tried using the mat_queue_mode 2 last night and it was pretty laggy. I hope they do come out with a better way to utilize both cores cause that would really help me out a lot
 
Back
Top