sedenion

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..

Edit: Misreaded the question... No, there is no link with FXAA... FXAA is a post-process added by Nvidia drivers... Here i speak about the topic origin, not about AA.

To be honnest, I have dificulties to see the difference, same between Textures Low/Medium :D However, with Textures to High, it seem a new shader pass is enabled, for enhenced specular and normal maps effects.

I second that. On my side, reading your post, I simply deleted (renamed) the Saved Games\DCS.openbeta folder to force DCS to create a full new configuration set from scratch including FXO and sahder cache. Before the operation, i was getting something like 40-50 FPS with sometime huge drop to 20 FPS for unknow reason. After the operation, with same quality settings, I get 60-80 FPS and the random FPS drop disapeared. I have to add some advices for people who don't have super-high-end graphic card (I have GTX 770), the Texture quality (both terrain and other) can have a huge impact on performance. My diagnostic is that huge textures forces drivers to store some data in the main RAM memory because the CG memory is completely full, and this has a huge impact on overall performances.

You cannot create a good normal map from a simple diffuse map, especially for complexe mesh like cloth.

As far as I know, no. But you are not forced to re-setup your binding all the time: If you simply save the binding for the moded version, and touch nothing while the mod is desactivated, when you reactivate it, you will retrieve your saved binding.corresponding to the modified pattern.