安装 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(越南语)
Українська(乌克兰语)
报告翻译问题
The problem is that SteamVR has many components that work in the background to make the VR magic happen. Those SteamVR threads sort of "fight" with Vtol VR to monopolise the CPU cores time and causes a mess that spikes the latency resulting in bad VR performance (retroprojection, smoothing etc) . This issue is caused "mainly" by the Unity Engine multithreading ♥♥♥♥ show, and "lack" of Vtol VR final optimization (Comprehensible, still in development). *** I believe physics are still not threaded***
The main objective here is to separate the SteamVR processes (mainly "vrmonitor" and "vrcompositor") from the game threads. Furthermore, AMD unique architecture is also to be considered for Ryzen users.
*Ryzen users:
Allow me to explain something. Some Ryzen CPUs have more than one CCD (chiplet design). In the case of the 3900X, there are two CCDs, each one contains 6 cores with 2 logical threads each, giving a total of 24 logical cores.
CCDs are separated from each other and connected by the infinity fabric (intel calls this technology "glue")
If one process would use 2 logical cores from CCD 1 and 2 logical cores from CCD 2, there would be time spent for the information to travel from CCD 1 to CCD 2 and so on. Most of the time, it would be much more logical and efficient to keep that process within one CCD if possible, specially when latency is crucial! But the windows scheduler dont know any better so we are here to help!
Vtol VR and Ryzen 3900X:
In this case I would choose SteamVR and other steam related processes to work in CCD2 and Vtol VR in CCD1, making this a strict rule and forcing it (No windows, today you do exactly what I tell you)
This would look like this:
CCD 1
________________________________________________________
C0 - Vtol VR
C1 - Vtol VR
C2 - Vtol VR
C3 - Vtol VR
C4 - Vtol VR
C5 - Vtol VR
C6 - Vtol VR
C7 - Vtol VR
C8 - Vtol VR
C9 - Vtol VR
C10 - Vtol VR
C11 - Vtol VR
________________________________________________________
CCD 2
________________________________________________________
C12 - vrmonitor, vrcompositor, vrdashboard, vrwebhelper
C13 - vrmonitor, vrcompositor, vrdashboard, vrwebhelper
C14 - vrmonitor, vrcompositor, vrdashboard, vrwebhelper
C15 - vrmonitor, vrcompositor, vrdashboard, vrwebhelper
C16 - vrmonitor, vrcompositor, vrdashboard, vrwebhelper
C17 - vrmonitor, vrcompositor, vrdashboard, vrwebhelper
C18 - vrmonitor, vrcompositor, vrdashboard, vrwebhelper
C19 - vrmonitor, vrcompositor, vrdashboard, vrwebhelper
C20 - vrmonitor, vrcompositor, vrdashboard, vrwebhelper
C21 - vrmonitor, vrcompositor, vrdashboard, vrwebhelper
C22 - vrmonitor, vrcompositor, vrdashboard, vrwebhelper
C23 - vrmonitor, vrcompositor, vrdashboard, vrwebhelper
***(I put all steam processes but it is not necessary)***
________________________________________________________
Vtol VR would be contained within CCD 1 and all Steam VR processes would be contained within CCD 2. This would one; improved the latency for Vtol VR and the Steam VR compositor by stopping the threads from constantly jump from one CCD to another and second; stop the threads from fighting to monopolise cores (increasing latency again)
***I also set Vtol VR, vrmonitor and vrcompositor to high priority processes, from normal***
***Remember to strictly enforce the affinities***
NEW *** I am also getting great results disabling SMT from the Vtol VR process (you manually force this by omitting the odd cores (disable C1, C3, C5, C7, C9, C11 from the Vtol VR affinity). I could shave off between 1 and 2 median ms from the CPU latency during high load missions*** NEW
***AMD Threadripper users would have to take into account the NUMA nodes***
With an intel, lets say, an hexacore for example, I would give to Vtol VR 4 cores (8 logical cores) and 2 cores (4 logical cores) for steam processes.
The results are "shocking", see for yourself. Spikes are GONE. This method would work for many other games or case scenarios, not only VtolVR.
The tool that I use for setting up all of this is "Process Lasso Pro", the tool I use for checking my CCD configuration is "Ryzen Master".
Process Lasso has a free version for trying it out.
If anyone needs help trying this out, let me know.
The dev isn't responsible for the windows CPU scheduler or the poor unity multithreading optimization.
On my system, Lasso Pro didn't give me the same performance as just disabling hyper-threading in the bios and also disabling threaded optimization in the Nvidia control panel.
I had another issue with Lasso Pro where editing in Unreal Game Editor was impossible, so I had to uninstall it.
gtx 980
16 go ram
Turned my frame rate to 70
But the biggest thing I saw improvement was changing codec to h264.
play multiplayer with father and brother all in a game the biggest thing is when you get close to another vehicle online playing with you it shutters a little bit but not unbearable.
Not sure why guy with a super computer is having issues lol.
Lower frame rate with it not being that detailed anyway in vtol compared to like fsx with add one being super realistic. Should have no issues.
My specs way below most
Most likely your CPU is the bottleneck here. The game is very CPU intensive, less heavy on the GPU side. 4 cores are in most cases not enough. I went from my i7 6700k to ryzen 5900X with same graphics card and it was a huge difference.
DCS performance depends a lot on the module (aircraft) you are using. For example the JF-17 module works beautifully for me but the AH-64D helicopter stutters like crazy and was virtually unplayable until I switched over to the new multi-threaded beta version.
I have a pretty robust system. 13600k, 32Gb RAM, and a 3080. Even with all of that, I still have to make a lot of tweaks and compromises with DCS. A lot of folks have been CPU-bound for years and years even with high-end CPUs because the game has been single-threaded up until about a month ago when they finally released the multi-threaded beta. I personally have experienced a good 20fps increase in a lot of situations which has made it much more enjoyable but there is still a lot of progress to be made. Not everyone has experienced big gains like that (for a variety of reasons) but the multi-thread version is still in its infancy and will almost surely improve as it ages and gets worked on. The devs are also supposed to be implementing Vulcan pretty soon which a lot of people believe will further streamline the rendering pipeline and increase frames even more.