Forum

Configs optimised for multi core

Created 21st October 2013 @ 12:22

Add A Reply Pages: 1

hycolours

_ainsley

So I’ve been told chris’ configs are optimised for just the one core
Is just actually true or just one of those bullshit things people say

if it is true, are there any max frames configs optimised for duel, quad, etc cores

AnimaL

Quoted from hycolours

So I’ve been told chris’ configs are optimised for just the one core

bullshit

the only thing you can gain using some of cvars that are not in the config (for a reason) is frequent crashes

/thread


Last edited by AnimaL,

There was a benchmark thread on tf.tv a while ago and people there found out that if you set “cl_threaded_bone_setup” from 0 to 1 you’ll increase your fps by 10-20 if you have a dual/quad core processor


Last edited by Solid,

ninya

Team

When multicore cvars first came out they were pretty instable but they’ve matured a lot. Chris left most out of his configs at the time for that reason. Try adding these, see if they’re stable.

cl_threaded_bone_setup “1”
cl_threaded_client_leaf_system “1”
r_threaded_client_shadow_manager “1”
r_threaded_particles “1”
r_threaded_renderables “1”
r_queued_decals “1”
r_queued_post_processing “1”
studio_queue_mode 1


Last edited by ninya,

octochris

(0v0)

Quoted from hycolours

So I’ve been told chris’ configs are optimised for just the one core
Is just actually true or just one of those bullshit things people say

You talk about optimisation as if it was a binary path — something that can always be added or removed from a config by default to gain a certain benefit for everyone. This is true in a lot of cases (even if the actual effects of the changes vary over time), otherwise having a config wouldn’t make sense in the first place; the reality is, though, that certain optimisations can only be so if you already know the target environment being used. In the case of these configs, there is no way for me to be able to know what your hardware is and take that into account before giving you a default. Even if I could, I can’t guarantee how something performs on certain hardware, especially when people’s reports about whether it works/doesn’t work on their hardware can often be attributed to other variables — their operating system, their architecture, whether it’s a full moon. So, unless I could own all the hardware and test it myself, I couldn’t tell you what is an optimisation and what is an introduction of instability in some cases.

Often, optimisations come with a cost; there’s a reason that they weren’t enabled in the game in the first place, after all. In the majority of cases these costs are visual: things which people (often) don’t consider of paramount importance when playing games competitively. These changes I am willing to make straight off the bat. There are some which we should be more considerate about making, however: those which other people have claimed cause crashes, those which other people have found to not be useful, those which you can’t demonstrate are useful in a test scenario. In the first case, the best compromise is to make it clear to people that these settings *can* improve your performance (or other aspects) if you are aware of the risks, and understand them. Crashes during matches are not something anyone likes to deal with, and it’s not something I ever want to inflict on people, especially if I knew that it could happen beforehand, and panned it off just for the sake of a few more FPS. I’d like to think that people understand why it is important to be conservative when picking the configuration options to be used when a configuration is designed to be run on generic, unknown hardware.

So yes: maybe these options will work for you, and I hope they do. If they do work, you will probably see a nice performance improvement in your game. This is the reason that I mentioned them in the config in the first place: so that people can try them out, and see how it goes, without me having to put my name on it and commit to saying “yes, I assert that these settings should work”. Unfortunately, this didn’t stop lots of people adding them in anyway and coming to me when their games crashed (these are the sorts of people who cannot read a header in a file to see that it is their own fault, and I don’t have time for them).

Try them out, see if they work. If they do, good stuff. They probably don’t work for everyone, otherwise Valve would enable them by default (and maybe they do now, what do I know, I’ve not played TF2 in years). Just be considerate when implying to others that just because these commands work for you, they must work for them. When you are really focused on optimising, that’s not often the case (in life, in code… in TF2 configs).

Best of luck.

ondkaja

IKEA

Quoted from ninya

mp_usehwmmodels “1”
mp_usehwmvcds “1”

i don’t understand why you would enable high quality facial features in an fps config

octochris

(0v0)

Quoted from ondkaja

[…]

i don’t understand why you would enable high quality facial features in an fps config

Those don’t enable high quality facial features, they enable the overriding the default models with higher quality ones, and the default faceposer objects with high quality VCDs (that were allegedly used for the “meet the X” series).

Why someone would enable them in an FPS config is beyond me (although I have no idea wtf I’m talking about any more, since I haven’t looked at a TF2 config in over a year).


Last edited by octochris,

ninya

Team

Quoted from ondkaja

[…]

i don’t understand why you would enable high quality facial features in an fps config

a bad copy paste, oops.

Add A Reply Pages: 1