Good job there, @fearlessfrog!
I’m off duty again and can start playing with my new toy. Will try this mod.
Unfortunately the rest of the family have started their summer vacations and the weather is lovely… I may have to spend time with them…outside…! 
3 Likes
Just gave it a shot on my 1070 rig. Default settings. Turned DCS PD from 0.7 to 1.0. Looked good and fast too. Only the clouds at longish range are borked. Quite happy with it, thanks AMD and mr Holger!
1 Like
First impressions with default renderscale 0.75 and sharpness 0.75: fps definitely higher, maybe in neighborhood of 20-25% (MiG-15 freeflight over Dubai). Also with some Hind Caucasus quick action similar results. Impressive!
There is also some degration of image quality due to lower render resolution like larger pixellation in building, some shimmering (without AA). But the image sharpness is a lot better than when lowering DCS pixel density or SteamVR render resolution. To my surprise, the clouds looked just fine over Dubai.
Installation was super easy, this is really worth giving a go.
Did you get a perceptible increase in FPS?
I’m thinking to try it with my 980ti…
Yes, a very large increase in FPS or at least smoothness. A slight degradation in image quality, offset by the fact that I could return DCS PD to 1 from 0.7. You should very much try it.
1 Like
Aye aye sir!
I’m interested to see what kind of headroom this gives me. I’m using a 3080Ti and a Reverb G2, but I run the settings low enough to get native 90fps, any framerate drops I have are from CPU usage. I wonder if running this FSR but then being able to turn things on like MSAA and upping the graphics settings will result in an overall better looking image, regardless of the minor render resolution decrease
2 Likes
I settled with the following settings:
- render scale 0.8
- sharpness 0.75
- DCS pixel density 1.0
- SteamVR resolution at 80%
- fixed 45fps motionvector
- DCS settings lowish
Hardware: OCd 8700K and 2080Ti, Reverb G2.
Now I am able to keep steady 45fps with reprojection even in heavy action and lot of smoke, which was not really possible before OpenVR FSR. Just tested with a demanding combo: Hind, Syria, instant action “H4 take down”.
1 Like
Have you ever run that app available on Steam, FpsVR? I use it regularly because I like how it will show me GPU and CPU usage and split frametimes for both as well, so you can figure out instantly if you are GPU limited or CPU limited. I only ask because I see you have a pretty strong GPU, I wonder if your CPU is really the reason you can’t hit 90.
In my current experience, I have SteamVr resolution at native, PD at 1, and have the a lot of the settings in game down and can get GPU render times under 10ms, 11ms is 90fps, so I know I have the GPU room. But on the ground, my CPU is the limitation most times, with CPU render time being 12-13ms or more, depending on if im online or in single player, mission complexity, etc.
Hardware:
5950X
32GB 3800mhz RAM
2TB NVMe drives
3080Ti
Reverb G2
Sadly it completely breaks Il-2 Sturmovik. 
1 Like
Noooo WHY
1 Like
Made the eye rendering go haywire. I had to close one eye to see enough to close the sim down again. Perhaps some tweaks will get it right again, I don’t know.
2 Likes
Well, scratch that mod then for me (and everyone I play with) because I need both to work lol
having it on DCS does not bork il-2. I put it into Il-2 as an experiment. It failed. Don’t worry, you still gat blazing frames in DCS 
3 Likes
A very long shot, but you could try some different numbers using this to reset the stereoscopic world scale
EDIT: The info in that article is old/wrong now. You can use http://localhost:27062/console/index.html to get to the SteamVR console in a browser, although IL-2 doesn’t seem to update dynamically.
It could be worth mashing Left Shift + Numpad Add (+) and Enter in game with this mod installed, as those keys by default alter the in-game stereo overlap IPD values.
Yes, I have, but did not have it running when testing today. I suspect that my setup is most of the time limited by GPU, but when lot of action happens, maybe scripting code running, CPU becomes the bottleneck. CPU is overclocked to 4.9GHz, so it is no slouch even it is couple generations old.
Give it a shot when you get a chance, I’d be interested to see what it says. 5000 series AMD is the fastest single core stuff on the market right now and I still see CPU frametimes dip in certain scenarios in a lot of games, not just DCS. Really wish I could make use of all these cores I have! lol Can’t wait for Vulkan implementation
1 Like
Sure, it’s a good idea.
Tell me about it! Software industry is frustratingly slow in utilizing multiple cores properly.
In the case of DCS, the legacy code two decades old is probably holding optimizations back. I guess they are rewriting the code piece by piece like all long-standing SW projects have to do eventually.
That’s because synchronisation is a frustrating problem. You can have all these cores working different aspects of the simulation, but if the one doing the radar physics is not spitting it out fast enough for the AI core to work with, thing’s are turning ugly quickly. Or so I imagine.
2 Likes
It’s more that OpenGL and DX v11 down have something called single thread affinity. You talk to the GPU via something called ID3D11DeviceContext and that’s not thread safe, so you have to have a single thread in charge of all rendering. That’s the issue for things that spend 80% of their time working out what the next frame should look like.
For DCS there’s probably a historical big ol main game loop (input, logic, render, sync), and access to all the shared game state assumes that just a single thread is talking to it - so that to make that multi-threaded (so it can be picked up by logical or physical cores) it has to be thread-safe, through the use of critical sections and mutexes. Code like that is just more complicated to write and debug, especially on an old code base and an external scripting library like the LUA interpreter.
The Vulkan port helps with that (as would going to DX12) as there’s a way for all threads to push things to a command buffer but it requires (a) a code structure that is built around async primitives or workers already and (b) a bottleneck where the render queue is really your real backlog.
We put a lot of hope on the Vulkan renderer for DCS but it’s really just a way to enable something that is going to require a lot of rework to an existing single-thread render title. The X-Plane people found out that there wasn’t a lot of initial gains other than just a really good way to start porting stuff over and getting it working faster. Vulkan for DCS might not produce a lot of immediate gains and might actually bring in some bugs - it’s a very low level technique that would be so much easier on a new game rather than an existing 20 year old code base.
12 Likes