Інсталювати Steam
увійти
|
мова
简体中文 (спрощена китайська)
繁體中文 (традиційна китайська)
日本語 (японська)
한국어 (корейська)
ไทย (тайська)
Български (болгарська)
Čeština (чеська)
Dansk (данська)
Deutsch (німецька)
English (англійська)
Español - España (іспанська — Іспанія)
Español - Latinoamérica (іспанська — Латинська Америка)
Ελληνικά (грецька)
Français (французька)
Italiano (італійська)
Bahasa Indonesia (індонезійська)
Magyar (угорська)
Nederlands (нідерландська)
Norsk (норвезька)
Polski (польська)
Português (португальська — Португалія)
Português - Brasil (португальська — Бразилія)
Română (румунська)
Русский (російська)
Suomi (фінська)
Svenska (шведська)
Türkçe (турецька)
Tiếng Việt (в’єтнамська)
Повідомити про проблему з перекладом
Btw, you could just pin the threads (for example with taskmanager).
You don't have to downcore the entire system just to downcore 1 program.
1.Badly coded game (it should only rely on cores *available* - ergo affinity)
2.Windows core affinity sucks - I guess it's nowhere near process isolation found on *NIX (I'm not implying it *could* be anywhere close, but I guess it's even further than I thought).
I took a look at the github page:
{ SECTION REMOVED - I failed to see the landing URL :P }
( I'll take a look at the code some other time )
You still haven't answered my question.
x > 16
OR
x >= 16 ?
It's crucial to know this as not a whole lot of people have above 16 threads while quite some have exactly 16-threaded CPUs.
a reliable solution would require for game devs to address it directly and patch their games which they wont do such long time after launch.
these games wont get patched. process lasso is a less intrusive solution, but doesnt always work.
I agree that windows cpu affinity might actually suck.
ps. I didnt get to run INVERSION tho.
First of all, originally I didn't pick on it, ( I guess I was too tired, or perhaps there was another reason ) but now I will:
You are using a HEDT type CPU for gaming.
Threadripper and the likes are known to have issues that CPUs like Ryzen 16+ core do not show...
Just this alone could potentially render your "solutions" incompatible with consumer-grade CPU SKUs.
I am not picking on YOU. This is nothing personal. This is simply a technical fact.
But let's give you a benefit of a doubt for a second.
Let's assume blindly that your "solution" would perhaps work...
At the end of the day - you don't really know, you are just choosing to trust Microsoft more, cue the company which has documented history of breaking software compatibility between system versions - in case you didn't know before - you do now...
They have changed multiple libraries over the span of the years, and they themselves are personally responsible for actual mountains of software no longer working properly on "new Windows version insert-name". Of course it's not always their fault, but it often is.
They have succeeded at utterly breaking backwards soft compat on multiple occasions, there WAS backlash, yet they didn't care.
This is what they do on a company level, they create forced obolescence - it's just a side effect that apart from breaking re-sellable software ( which continues to get newer versions, often "need to pay for" newer versions at that ), they also broke tons of "single release" software, eg many games.
Personally I wouldn't coin it a " "fact" " that "it's definitely the game's fault". You don't know that. You shouldn't assume that. Especially not with company such as Microsoft involved.
In your own words "( you are ) not a programmer".
Let me tell you:
it's entirely possible to get a temporary outcome consistently enough to misinterpret it as a constant, instead of variable...
I believe you, but I also have a belief it's always possible to use software incorrectly even after multiple attempts.
It's possible you used it wrong. Just saying...
No, actually ( in MOST cases ), a "reliable solution" would be for Microsoft to not retroactively change older libraries' code - you know, kind of changes where OLDER SOFTWARE ( released before the change ) relies on THIS EXACT CODE. They could also try to design their OS intelligently and not hap-hazardly.
It is UNREASONABLE to expect every company who ever made software to be run on Microsoft Windows systems, should support it till the end of universe lifespan. Companies go out of business, developers change jobs, some software even becomes abandonware, yet a system lives on ( usually ).
If you get a library X of version let's say 1.0, this version should remain FOREVER STATIC - that's how it's supposed to be done in programming world!
If you want to update it, say, make a functionality superset, you either A. Bump the version OR B. You make a new library.
But then MS, in their ultimate " "wisdom" " on several different occassions changed the underlying libraries without bumping the versions!
OR they straight out FORCED software to use newer libraries' versions than the software is requesting - in SOME ( rare ) cases this has zero impact by a sheer LUCK, but in many cases this straight out makes software malfunction or not work at all!
If Microsoft keeps screwing stuff up, you just can't expect everyone to constantly patch their software.
The devs were given libraries to work with, then they relesed their software, then years passed, then MS changed the underlying libraries.
What are you expecting devs to do?
Sit back eg 10 years later and rebase the whole code?!
This is exactly backwards to how it's USUALLY done in programming world!
And it's MICROSOFT who is doing it wrong!
And YES, MS *has* changed their CPU governor algorithm, their CPU affinity code, their CPU load balancing, etc, over the years. It definitely DOES have impact on older software.
It's not unreasonable to assume at least SOME software's auto-detection code is suddenly incompatible with whatever changes MS made.
This is probably the case in this specific problem.
This isn't the first time a problem such as this surfaced you know?
It's nothing new.
Is a free[/b]mium[/b] software, 3rd party software at that!
It has a lot of functionality beyond just CPU affinity, so naturally, there's more room to misuse it.
Use official Microsoft tool instead:
https://www.techpowerup.com/download/microsoft-interrupt-affinity-tool/
( or here, but this may be an older version possibly )
https://web.archive.org/web/20201111193913/https://download.microsoft.com/download/9/2/0/9200a84d-6c21-4226-9922-57ef1dae939e/interrupt_affinity_policy_tool.msi
( disclaimer: been a while since I used this tool, I don't remember exactly if it allows changing games' affinity, my apologies if I misremembered )
By the way, it's been a while since I checked this ( I no longer use Windows as a daily system ), but I'm fairly sure you can set CPU affinity for a process in a taskmgr... You should try setting it ( for the game ) to 'real cores' only, and or to "only first few ( real ) cores" - some older games behave badly if they see too many cores ( be it due to MS changing relevant code, or the game engine being badly coded )...
I think the intent is clear. And these 2 parts are woefully unnecessary to add...
Also, for general troubleshooting I recommend PCGW.
While in this case the info is not there, in many other cases the site is very valuable resource.
https://www.pcgamingwiki.com/wiki/Deus_Ex:_Human_Revolution
As a closing note - I want you to understand that I am NOT against you personally, I just want things to be accurate, without arbitrary assumptions and without interpreting possible flukes as "definitely proper". No offence. And no hard feelings.
By the way, NICE NECROPOSTING...
Only a whole 1.5 year after last post...
@Rage dude, no point in quoting the whole article, it makes reading the topic harder for others :)))
TLDR:
I have been learning IT privately for most of my ( relatively not very long ) life. I self learned 95+ % ( I have virtually no "paper trail" ).
I know few prog lang to an "undisclosed degree". I have spent years digging through bugtrackers, debugging issues on my end, sometimes helping others. I also have "undisclosed" level of gamedev knowledge. AND I switched to Linux as my daily system full time few years ago, have done considerable amount of debugging NIX issues since then... ( before that I spent big chunk of my life privately wrestling with Microsoft's garbage software, and their many piss poor design decisions... )
While I am definitely not the most qualified person to fix certain issues, I debatably do know more than many other random people ( kinda blanket statement lol ).
I don't really know how to answer your question, lol.
At the moment I don't consider myself a programmer, bc it's not something I do for a living ( at least not rn ).
I do however intend to "properly" learn some things someday / "make my knowledge better", eg "C".