Measuring Performace

I need a lot of help here. I'm not completely ignorant of computers, but my experience with tuning is very limited.

I'm trying to tune-up my rig to get some better performance out of it in VR (Rift1), which is miserable at the moment.

So, the first step in my mind is to be able to measure performance. I'm using Afterburning currently, as it gives me most of the necessary telemetry data in one set.

However, to record only the core I'm using for DCS I have to set the affinity after starting DCS, which is not really a problem, just another step in the process each time I start testing. But, from my understanding DCS uses two processes, one for audio and one for everything else. But I cannot find a process in Windows Task Manager for audio, or am I misunderstanding this?

DCS is a single process that can use 2 CPU threads/cores. However it sounds like you told windows to restrict it to a single core for both threads. This will dramatically decrease performance. Additionally, DCS 1.5 cares far more about CPU clock speed than what GPU you have. At 3.8 GHz, your CPU is far too slow for DCS 1.5 in VR at any graphics setting. You should still see 45 fps in DCS 2.x, and thanks to the graphics card, you should be able to run it at max detail except for trees and visibility range. Even in DCS 2.x, your CPU must run above 4.7 GHz to fully utilize the GTX 1080 TI. I have a 1080 TI and an i7-8700k at 4.7 to 5.0 GHz, depending on the profile. That's the clock speed required to get it running smoothly with the GPU fully leveraged. Even then, DCS 1.5 runs between 19 and 90 fps with GPU usage rarely exceeding 30%. So 1.5 is just trash in general in VR.

Hi BeastyBaiter, thanks for answering.

DCS is a single process that can use 2 CPU threads/cores. However it sounds like you told windows to restrict it to a single core for both threads. This will dramatically decrease performance.

Actually, since my understanding was that DCS is 1 native (unthreaded) process for audio and 1 native for the rest, and no threading at all, and I assumed that the 2 independent processes, since unthreaded, would each use an entire physical core.

So I set the affinity for DCS.exe to cores 0 and 1 in Windows Task Manager (actually hyper-threads), because that is a single physical core, but I could not find another process in WTM to assign to a second physical core.

So if DCS.exe is actually 2 threads, assigning affinity to cores 0 & 1 will actually do exactly what I want, which is to isolate DCS processing to a subset of hypere-threads, which I can monitor in Afterburner.

Do you know if this assessment is correct?

Additionally, DCS 1.5 cares far more about CPU clock speed than what GPU you have. At 3.8 GHz, your CPU is far too slow for DCS 1.5 in VR at any graphics setting. You should still see 45 fps in DCS 2.x, and thanks to the graphics card, you should be able to run it at max detail except for trees and visibility range. Even in DCS 2.x, your CPU must run above 4.7 GHz to fully utilize the GTX 1080 TI. I have a 1080 TI and an i7-8700k at 4.7 to 5.0 GHz, depending on the profile. That's the clock speed required to get it running smoothly with the GPU fully leveraged. Even then, DCS 1.5 runs between 19 and 90 fps with GPU usage rarely exceeding 30%. So 1.5 is just trash in general in VR.

I actually setup my rig with DCS 2.x in mind. I had read that since EDGE would be using DX11 to push most of the processing out to the GPU. I originally had an Sapphire Radeon R9 295X2 installed, but the dual GPU's simply didn't work so well in Crossfire, although they are on the same unit, and when I decided to move to a CV1, I knew Crossfire was not supported. It was simply a shame to have dual GPU's and never get the processing power out of but one, so since Nvidia has announced the 1080Ti at about that time, I switched over to a Zotac Nvidia GeForce GTX 1080 Ti Amp! Extreme.

I was aware that my CPU might be a bottle neck when I purchased it, but I also left a path open to climb up, without having to invest in a new system board as well, which was a dead-end with my old system. Also, from what I had read up to that point, OC'ing the i7-5820K to 4.4Ghz could be done with no great difficulty, although I've never done any OC'ing, other than turning on OC-Genie on my system board, which is no task at all. But that was all before Oculus *sigh*

I've been mostly flying in 2.x with the CV1. Although the performance is not excellent I've been living with it. But with 2.5 right around the corner, I decided it was time to start tuning up my system to get the most out of 2.5 right from the start.

So the first step would be logically, to be able to measure performance reliably.

On a side note, I've run into some other issue I hadn't expected at all already. Somehow I've managed to configure something in my graphics card that it locks FPS to 30 no matter what I do. I've either turned everything off in Nvidia Control Panel, or set it to defer to DCS, and then set the default settings to VR in DCS, but even with the HMD detached and only running on my monitor, I still only get 30 FPS. I used to get over 90 on high settings without Oculus, IIRC.

Then out of frustration, and just to see what happens, I turned everything up to max in DCS, and even with CV1 I'm getting 30 FPS as if it were locked in somewhere (single player mission, without any other aircraft or vehicles).

Even when I start Charnwood mission 1, which has probably about 30 other AC and about 50 or more ground vehicles on both sides, I get a solid steady 20 FPS on the ground, which go up to 30 in the air.

if you have the oculus tray tool you can use it to see the oculus overlays in VR.

use the performance overlay. to see what performance you are getting in the HMD.

this gives you more accurate frame counts as you look about and gives a % of system used.

In regards to the frame rate being locked to 30, that's probably MSI afterburner. I had that same issue at 89 fps a while back. Had to uninstall afterburner, physically remove the 1080, replace it with an AMD card, wipe all the drivers and then reinstall the 1080 TI. Needless to say, I will never install afterburner again.

For multithreading, this is a somewhat complicated topic I'd rather not get into here. But by default Windows will sort it out for you. If you are manually assigning affinity, then it is best to put it on as many physical cores as possible. To that end, I recommend logical cores 0 and 2 or 2 and 4 and so on. Make them either all even or all odd core id's. But as said, there is no real reason to do this.

if you have the oculus tray tool you can use it to see the oculus overlays in VR.

 

use the performance overlay. to see what performance you are getting in the HMD.

 

this gives you more accurate frame counts as you look about and gives a % of system used.

I use the Oculus Tray Tool (one of the best free SW I've ever installed). I originally used the SDK to get the performance overlay, but with the OTT, it's so much easier to do everything.

The things I don't like about the Performance Overlay are that it's so -right in your face- in the way :(, and it doesn't tell me anything about CPU usage, which is so important with Oculus, so you cannot tell if a framerate drop is from the CPU or the GPU.

Afterburner records everything you want so you can go back and check what happened with a number of things at the same time, but you cannot get an on-screen display in the HMD :cry:, which makes it difficult to know exactly what was going on right when you get some anomaly.

In regards to the frame rate being locked to 30, that's probably MSI afterburner. I had that same issue at 89 fps a while back. Had to uninstall afterburner, physically remove the 1080, replace it with an AMD card, wipe all the drivers and then reinstall the 1080 TI. Needless to say, I will never install afterburner again.

 

For multithreading, this is a somewhat complicated topic I'd rather not get into here. But by default Windows will sort it out for you. If you are manually assigning affinity, then it is best to put it on as many physical cores as possible. To that end, I recommend logical cores 0 and 2 or 2 and 4 and so on. Make them either all even or all odd core id's. But as said, there is no real reason to do this.

I found the issue with the 30 FPS lock, and I have no idea why I had never noticed it before. It was the 'autoexec.cfg' in '..\Saved Games\DCS.openalpha\Config\'. I found 'options.graphics.maxfps = 30' in that file, with some help from somebody on FB, and I have no idea of how it got there, because the creation/update timstamp was 14-Jun-2017. Very strange.

Anyway, the point of setting the affinity on DCS.exe is not to enhance performance, but to better measure it. I could simply record all CPU's in Afterburner, but I'd never really know which CPU DCS.exe was using at any given time. I might be able to guess, simply on hand from the usage, but without affinity set, DCS.exe could jump from one CPU core to another at any time, although not probably. Anyway, even if it didn't, I would still have to record all CPU's and have a bunch of junk data I don't need or want, which makes analyzing performance even more of a task.

I'm wondering, if I don't have affinity set on a process, is there any way to record which CPU it is using over time, or even at any given time? I don't think I've ever seen that.

DCS is a single process that can use 2 CPU threads/cores. However it sounds like you told windows to restrict it to a single core for both threads. This will dramatically decrease performance. Additionally, DCS 1.5 cares far more about CPU clock speed than what GPU you have. At 3.8 GHz, your CPU is far too slow for DCS 1.5 in VR at any graphics setting. You should still see 45 fps in DCS 2.x, and thanks to the graphics card, you should be able to run it at max detail except for trees and visibility range. Even in DCS 2.x, your CPU must run above 4.7 GHz to fully utilize the GTX 1080 TI. I have a 1080 TI and an i7-8700k at 4.7 to 5.0 GHz, depending on the profile. That's the clock speed required to get it running smoothly with the GPU fully leveraged. Even then, DCS 1.5 runs between 19 and 90 fps with GPU usage rarely exceeding 30%. So 1.5 is just trash in general in VR.

Ahem...

My man! Thank you for confirming my thoughts about the CPU bottlenecking me. Using EVGA Precision I haven't been getting full capacity out of my video card with either DCS 1.5 or 2.0. Neither was the bus saturated. But Precision wasn't measuring my CPU, so I only suspected that it was the weak link.

So you're telling me I should be running maxed visual settings if I can clock the CPU to 4.7? At what pixel density? The readability and presence of the guages goes up dramatically on CV1 with increase of pixel density; which is a plus for me...

Sorry to hijack the thread. Would appreciate a PM if the answers get cumbersome for the mods...

-Erik

It's related, so should be fine. If you are fine with 45 fps, then more or less, yes. I'd switch AA off and use PD at 1.4-1.7 instead and set heat blur to low. If you want 90 fps, then you will need to drop shadows to medium, visibility range to high, turn off clutter/grass, set trees to 10km and use terrain flat shadows. That is for NTTR.

I recommend going more AA (2X at least, 4X if you can) instead of PD above 1.4.

The reason for this is spotting.

PD directly reduces the size of the pixels that are the target at long range.

AA doesn't reduce their size... but just blends them.

I can spot from further distance with 2-4XAA and 1.25PD than with 1.8PD and no AA.

I recommend going more AA (2X at least, 4X if you can) instead of PD above 1.4.

 

The reason for this is spotting.

 

PD directly reduces the size of the pixels that are the target at long range.

 

AA doesn't reduce their size... but just blends them.

 

I can spot from further distance with 2-4XAA and 1.25PD than with 1.8PD and no AA.

I'm not doubting, that your experience with AA is better than with PD, but "PD directly reduces the size of the pixels" is illogical. The "size" of pixels is determined by the HMD and nothing else. A pixel is always a pixel.

I'm not doubting, that your experience with AA is better than with PD, but "PD directly reduces the size of the pixels" is illogical. The "size" of pixels is determined by the HMD and nothing else. A pixel is always a pixel.

PD increases the resolution at which the scene is rendered. As an example lets use nice round numbers... So, if you have a scene rendering at 500x500 and you increase your PD to 1.5, you effectively are now rendering at a resolution of 750x750. To present this to the HMD, the 750x750 image must be downsampled to 500x500. If in both scenarios, rendering at 500x500 a bandit is 1 pixel at a distance, and also 1 pixel at a distance at 750x750, when you downsample the larger image to 500x500 the single pixel will be blurred some, because it is now technically smaller that 1 pixel in size from the image reduction. This is what he is trying to explain.

I made this image long ago to try to help explain. It is created using the same techniques, but obviously not ingame. If you look at the first dot, vs the 3rd, you can see what I mean, this is only PD change, no MSAA

PD increases the resolution at which the scene is rendered. As an example lets use nice round numbers... So, if you have a scene rendering at 500x500 and you increase your PD to 1.5, you effectively are now rendering at a resolution of 750x750. To present this to the HMD, the 750x750 image must be downsampled to 500x500. If in both scenarios, rendering at 500x500 a bandit is 1 pixel at a distance, and also 1 pixel at a distance at 750x750, when you downsample the larger image to 500x500 the single pixel will be blurred some, because it is now technically smaller that 1 pixel in size from the image reduction. This is what he is trying to explain.

 

I made this image long ago to try to help explain. It is created using the same techniques, but obviously not ingame. If you look at the first dot, vs the 3rd, you can see what I mean, this is only PD change, no MSAA

Yes, I understand the concept of over-rendering through PD aka SuperSampling, which is then down-rendered to the HMD native resolution. There is one flaw in your explanation: "If in both scenarios, rendering at 500x500 a bandit is 1 pixel at a distance, and also 1 pixel at a distance at 750x750". Why should it do that, other than possibly in a very narrow margin of cases. In all cases, SS will provide a more distant rendering than non-SS.

Why? From reading about how DCS treats distant AC which would mathematically be depicted as less than one pixel size, but could still be depicted as a not so dark pixel, the DCS engine simply does not depict these at all, where as with SS the distance at which the SuperSampled rendering will still depict an AC, is greater than without. Upon down-sampling the SS-render, the pixel will then be simply not as dark.

Here is a description of of how it works Nvidia Dynamic Super Resolution (DSR)

EDIT: BTW, from what I've read, mixing SS and MSAA is counterproductive. You should use one or the other.

Yes, I understand the concept of over-rendering through PD aka SuperSampling, which is then down-rendered to the HMD native resolution. There is one flaw in your explanation: "If in both scenarios, rendering at 500x500 a bandit is 1 pixel at a distance, and also 1 pixel at a distance at 750x750". Why should it do that, other than possibly in a very narrow margin of cases. In all cases, SS will provide a more distant rendering than non-SS.

 

Why? From reading about how DCS treats distant AC which would mathematically be depicted as less than one pixel size, but could still be depicted as a not so dark pixel, the DCS engine simply does not depict these at all, where as with SS the distance at which the SuperSampled rendering will still depict an AC, is greater than without. Upon down-sampling the SS-render, the pixel will then be simply not as dark.

 

Here is a description of of how it works Nvidia Dynamic Super Resolution (DSR)

 

EDIT: BTW, from what I've read, mixing SS and MSAA is counterproductive. You should use one or the other.

I don't know the inner workings of how DCS renders things at a distance. I just know that leaving on my monitor, if i render at 1080, the same scene at 4K, objects in the distance do not reduce < 1 pixel in any fashion. Meaning, if its 1 pixel at 4k, its 1 pixel at 1080p.

Do you mean, if you set your resolution to 1080 in DCS, you see a distant AC rendered as a single pixel, but the same frame rendered at 4k resolution still depicts the same object as again only 1 pixel?

Is this in both DCS 1.5 and 2.x?

How can that be?

The thread(s) where I read about where DCS drops rendering was in the many discussion about imposers, which do not exist in DCS any more.

Do you mean, if you set your resolution to 1080 in DCS, you see a distant AC rendered as a single pixel, but the same frame rendered at 4k resolution still depicts the same object as again only 1 pixel?

 

Is this in both DCS 1.5 and 2.x?

 

How can that be?

 

The thread(s) where I read about where DCS drops rendering was in the many discussion about imposers, which do not exist in DCS any more.

Correct, this is what i see, (if you can see it in 4k, pixels are so small) 2.2 and 1.5 this is the same thing. As for imposters, thats usually a discussion of LOD, but even with the lowest LOD, a dot is a dot to the rasterizer. This is why if you get in a plane in VR, with 1.0 PD and no MSAA, you can see 120's come off the rail on a bandit at like 20 miles no problem (obviously you shouldnt launch this far). The dot is just visible. In 4k, this would be hard to see, because the pixels are much smaller.

I totally should have used a term like rendered pixel or logical pixel or something... But yeah... This is exactly what I'm talking about.

Correct, this is what i see, (if you can see it in 4k, pixels are so small) 2.2 and 1.5 this is the same thing. As for imposters, thats usually a discussion of LOD, but even with the lowest LOD, a dot is a dot to the rasterizer. This is why if you get in a plane in VR, with 1.0 PD and no MSAA, you can see 120's come off the rail on a bandit at like 20 miles no problem (obviously you shouldnt launch this far). The dot is just visible. In 4k, this would be hard to see, because the pixels are much smaller.

I honestly don't know if you think that running a full screen program at 4k shrinks the pixels on your monitor to be physically smaller to fit more into the same space, because that's the way you sound to me.

I totally should have used a term like rendered pixel or logical pixel or something... But yeah... This is exactly what I'm talking about.

No, you should not be making up terms. Use the ones which exist; they have worked until now for everybody to describe what they mean.

If you cannot find a term for what you are describing, then you are probably not understanding something correctly, especially when we are talking about man made technology, because it's man made, so they've already given names to all of its parts and concepts.

Rendered Pixel would only make sense with regard to pixels which are not rendered. On a monitor pixels which do not display are called dead pixels.

Look, guys--I honestly don't believe I have to explain this--a monitor has a fixed raster of pixels. They are physical like the street lamps on the street where you live. You can only have more streetlights on your street if you physically add more streetlamps, by digging up the ground to lay cables, or hanging them from masts, installing a lamppost in the ground and hanging a streetlamp on it. It's no different with your monitor. There are real 1-1 physical connections to the diodes which light and dim in coordination to create the pictures you see on your monitor.

If your monitor has a native resolution of 1920×1080, that means there are physically 1080 pixels in height and physically 1920 pixels in width. This cannot be changed, any more than you can change the number of doors on your car, without using hammer, angel grinder, and welding torch.

Assuming a 1920x1080 native resolution monitor. If you do not use SuperSampling the number of pixels per frame our graphics card must calculate is 1920 x 1080 = 2,073,600.

If we apply PD of 1.5, we are telling the graphics card to first create a picture with the masses of ((1920 x 1.5) x (1080 x 1.5)) = 4,665,600.

When we over-render it happens in the processing and memory of the graphics card. Since this over-rendered frame of 4,665,600 pixels cannot be displayed on our 1920x1080 monitor, which can only display 2,073,600 pixels, it must first be shrunk or down-rendered to 1920x1080. The graphics card calculates how to basically change 3 pixels in their colors and intensity down to two pixels, so that the resulting down-rendered picture looks as close as possible to the original in-memory-only picture. During the process of down-rendering, a Gaussian filter is applied to act as an anti-aliasing tool.

This process of first rendering a much larger picture, and then shrinking it, allows for much crisper images, especially where hard edges are depicted, such as with writing, and eliminates the need for using other anti-aliasing tools, which often require a relatively large amount of time and calculating power to implement.

Captain Orso, i dunno what else to say, maybe im just not explaining myself correctly, you obviously have a great understanding of how things work, so maybe we are saying the same thing, maybe we arent, but when I put on my oculus with 1.0 PD and see missiles come off the rail at 20+ miles and take a screenshot... then the same on a 4k Monitor by taking a screenshot and zooming into the images to see it... its 1 pixel, Try it for yourself.

 

EDIT: BTW, from what I've read, mixing SS and MSAA is counterproductive. You should use one or the other.

I have to disagree with this, based on my observations.

With AA off, regardless of PD setting, I get horrendous “shimmering” along any straight edges (buildings, power lines, etc. It doesn’t even seem to matter if I go all the way up to PD 2.5, it’s still there, and it completely breaks immersion. It happens at some distance as well; looking at Vegas, for instance, from the Helipad at Nellis, it almost looks like the landscape between is crawling with ants. At 2xAA, it’s greatly reduced, and at 4xAA, it’s gone entirely.

The cost (aside from the added graphics card workload), is less distinct text on gauges, etc. which increasing the PD corrects, in addition to providing more depth to things like the gauge bezels and the gunsight glass on the P-51.

So I would argue that each setting addresses the weaknesses of the other, and using moderate amounts of both yields better graphical fidelity.

-Erik

Captain Orso, i dunno what else to say, maybe im just not explaining myself correctly, you obviously have a great understanding of how things work, so maybe we are saying the same thing, maybe we arent, but when I put on my oculus with 1.0 PD and see missiles come off the rail at 20+ miles and take a screenshot... then the same on a 4k Monitor by taking a screenshot and zooming into the images to see it... its 1 pixel, Try it for yourself.

If I may...

The difference between the rift display and 4K is a factor of 4, so for every one rift pixel, the 4K monitor displays 4. It can’t go the other way, though; the rift can’t display 1/4 of a pixel. But the game is calling for a pixel in that frame at that spot to represent the new object (missile), so a pixel is generated. A whole pixel, since a portion of one can’t be generated.