sedenion

Actually, i guess the thread-bouncing is not even a Windows kernel behavior, but default behavior of chipset/firmware. I guess kernel only request some control to firmware to force this or that... My theory is that this behavior, as said before allow to reduce power consumption, but, if you read between lines, this litterally mean: Preventing the CPU to overheat.

Default setup for swap under Windows is to set the swap size equal to RAM size... which is clearly disk space wasting. I recommands to always set the swap size manually to only 1Go as fixed size, or maybe 2Go MAXIMUM. This is theoritically largely sufficient, since swap should not be considered as a standard memory management, but as rescue memory management: You need swap ONLY if your RAM is full. Setting swap to fixed size of 1Go, let you know quickly when your system is out of memory, since Windows will warns you about. Otherwise, Windows will simply fill up the swap, and becomes slow.

I don't think you will observe an huge difference with or without sound. I don't know how DCS sound engine is programmed, but, speaking of my own personal experience, the need to put sound process in its own thread is not about heavy CPU usage, but about time and buffer switching management with varying FPS... Sound process needs buffers to be switched at regular time (streaming), if you include this process withing your main loop (where FPS can be high or low depending situation, system, etc), Its like trying to synching two different worlds (a one can retard the other)... Putting sound with its own "while(true)" clockwork in a separated thread solves the problem, even if its not "multi-core".

Most (if not all) of these simulations are not done in real-time and are not interactives. Softwares design and purposes are not the same, also the kind of simulation is not the same, they are very specialized to a particular task, they are not (less) limited by memory and real-time management. In a game physics engine, you optimizes constantly to select what must be computed and what don't need and you can have a lot of exception. For example, you don't comput the collision test of a bullet to another body the same way than a collision of a body with another or with the ground... Also, paralelizing things like collision test is not straitforward. Using paralelization, you - for example - send two buffers of raw 1000 values as input, one algorithm to comput something 1000 times with this pair of 1000 values and you get an output of 1000 resulting values... This is ok to update positions of a bunch of particles, but to test a collision, this is inadapted, because the data you need is conditionnal and "an exception" by definition: Is there a colision (True or False) ? If yes, where it is ? (what vertex, at what velocity, at what position. Parallelization is not designed to output the result of a conditional branching, where output data is not the same format and nature than the input ones, this is designed to comput the same thing, X times, and output X results of the equation. I don't mean this is impossible, but, when you are about to implement such paralelization, you ask yourself: Is there a real benefits implementing paralelization of thousand of useless computs done quickly than regular way, instead of optimizing the regular way to avoid useless computs by conditionnal testings and get directly what i need to continue my process ?

That's was my intuition...

That's what I said... However, bolek pointed something I did'nt known; However, as programmer, I wonder if such thing would really increase performances much more than letting OS and firmware optimizing it theirself...

This is simply two differents things... VR is about drawing the scene twice, from two different cameras, one for the right eye and one for the left one... Frame buffer size is a secondary problem here.

No, there is a difference between rendering a scene ONE time on a big frame buffer which is later splitted, and rendering a scene TWO times on - no matter - one or two buffer(s)... Viewport is not necerssarly "point of view"... there is no "black magic"... rendering from two points of view mean, calculating perspective, geometry, lighting, etc, two times for the same frame...

The key part is not the installation folder, but the config folder in "<user>\Saved Games"...

You maths forgot something fundamental: With VR you are not only changing resolution, but you also render the scene twice from two points of views, this change almost everything...

This is the right way to understand multithreading. However, using separate thread(s) for some task can help improve overall performances. For example, runing sound process within a dedicated thread can help, because sound is matter of streaming buffers highly related to time, and it's better to let this working its own way separated from the main application loop... I doubt the Audio is on a "different core". It is highly probable that audio process is in a separated thread, but not a separated core. The simple reason is that: I don't know any way to dedicate a particular process/task to a particular core... nothing in Windows API allow that... If this is possible, i'll be curious to know how this is done.

This simply mean this is not the Nvidia's setup who make the diference (which is logical), but the DCS's reload. Did you try to delete the Fxo and Shader caches from your config folder ?

You two are both right and wrong... first, lets separate two things: 1) Multi-threading 2) Multi-core/Paralelization Multi-threading exists from long before the democratisation of multi-core CPU. you can deduce that you can have a multi-threaded application which is not multi-core at all. As I explained in another place, threads are managed by the OS Kernel, you don't have choice to dedicate a thread to a particular CPU core. You only can define some priority, the kernel manage all that for you. In this context, Multi-threading is hell to manage with real-time applications like DCS, where all must be synchronized, where all events must be handled the right time to create consistent interaction. Creating a sperated thread for "physic simulation" in paralelle of "scene object motion" is simply an heresy since both are directly linked. However, it is possible now, to create a single-threaded application, which use some API that are exploiting GPU or multi-core CPU to perform parallelized computing, quicker than an usual loop within the main thread. However, this, is NOT "multi-threading"... this is "parallelization". This is already how that works with DirectX/OpenGL using GPU: The application have ONE thread, and when it is time to compute graphical things, the thread calls API functions (DirectX or OpenGL) which will computs things using GPU... However, this is not multi-thread at all: The thread is WAITING that DirectX/OpenGL functions returns (finished their job) to continue. Using API like OpenCL, it is now possible to create a similar behavior to take advantage for multi-core CPU and GPU to computs some parts which can be paralelized, like, as you mention, a bunch of similar computing. However, this is not as simple as it appear to design a physics engine which can really take advantage of this...First, because using API like OpenCL is full new world to understand, and because the heavy and hard part is not the velocity from gravity vector computing (this is very cheap) but the collision détection, and here, parallelizing things is not as simple as a fixed function without branching, because you have a lot of branching and complex algorithms...

you did an acrobatic backup/config management.. OvGME should have warned you at first attempt (probably a mistake on my side), after that, i don't know exactly what happened, but it seem clear that something did'nt work correctly.

With deferred shading this is very improbable... DS In-game MSAA is working at a totally different stage than where Nvidia apply it automatically. I second that such observation are placebo due to some unpredictable behaviors...

As far as i know, you don't have control on such thing... You simply create a thread, and the OS's (Windows in this case) kernel manage it for you. Assigning a specifical thread to a particular core is not allowed in common API. Look by yourself: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682453(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms686277(v=vs.85).aspx Exploiting multi-core require using a specific library which work at low-level close to hardware, and this is used for very specific tasks which can be "parallelized" Never seen that on my life... but why not. This still true... 2 cores probably helps to separate game from OS background tasks. What will really make the difference is : - CPU design - CPU frequency - CPU cache/registry management... The same CPU design with same clock, I doubt you will see any difference between a 4-cores vs 8-cores... Except the price and marketing...

With multi-core CPU, you will VERY rarely see a core maxed at 100%... This behaviour would be very strange. I can launch an infinite loop of matrix multiplication, i will never see my CPU maxed to 100%... tasks are divided between cores...

The graph does not mean anything concerning single or multi-threaded application. Motherboards/chipsets are dividing tasks (including single thread apps) since the introduction of multi-core CPUs. There is also a misunderstanding about "CPU bottleneck". An application like DCS is designed to run as fast as possible, so to take advantage of all "free time" of CPU, in other words: use 100% of the CPU every time. In this context: everything is a "bottleneck" since everything is intented to run as maximum stage... If the "Graphical part" is quicker, the "graphical part" will wait for the CPU to finish his job, if "CPU part" is more quicker, the CPU will wait for "graphical part" to finish his job... You will ALWAYS have something that wait for another thing, this is limitless.

This is the same... FOV (Field Of View) is an angle of a cone/frustum through objects are projected on a surface (this is what we call Perspective). What DCS (or any 3D engine) does, is to project the world into a flat rectangle (your screen), like a camera. You cannot simulate a "eye FOV" on a screen, because your eyes are not flat, but round, your brain make a lot of thing to let you appreciate the world as wide view. When you play DCS, its like seeing the world (DCS's world) through a very small window. If you want the DCS Fov to be almost correct considering your actual eye's field of view and screen size, you have to set the FOV to something between 15° and 30°... You will only have a HUD, a very small part of the cockpit...

I see many people complaining about performance who are setting this value at very high level... however, this parameter is probably the most important framerate killer. Visible range increase count of objects to draw per frame, which increase both CPU usage (scenic computing), GPU usage (polygon draw), and memory (additionnal textures)...

This is not odd. Increasing textures quality and such things will fill up the memory without increasing operations complexity. However, by filling GPU memory you could induce performance hit due to the need to transfert data from RAM to VRAM and vice versa, which is slower.

the "other AA type from Nvidia" you mention is in fact MSAA setting intended to replace or enhance game setting. But with Deferred Shading this setting has no (or very little and unpredictable) effect due to how Deferred Shading rendering works. I reproduce here little shema to uderstand why:

Reducing video memory usage might greatly help: - Reduce Terrain Texture to low - Reduce Textures to medium - Reduce preload radius to ~30 0000 - Reduce visible range to bellow "High" - Reduce shadow quality to Medium With that, you could set tree to 100% without losing performance

The pattern is that when you don't have enouth 1) Graphic Card Memory 2) RAM memory, you have shutter/performances lose. 1) When Graphic Card Memory is full, the drivers uses the common RAM memory to store textures and geometry, and must transfert data from RAM to CG memory more often, this is slow, this induce huge lose of performance. 2) When RAM is full, first, allocating memory become hard for OS, and it finally use the Swap memory: Your hard Disk to write/read data... Swap is terribly SLOW, even with an SSD, the access and transfert time is much more slow than from RAM.

There is no link with FXAA... No matter what you do after or before you enabled FXAA in Nvidia drivers... Personally I run with MSAA 2x and Anisotropy filter 8X ... FXAA give no real improprement (this is a dirty AA) with blurry text..