ShaunOfTheFuzz

Yes, it always fixes the problem immediately, but if I try using SRS or viacompro then the problem returns. It's totally bizarre because I've always used viacompro and srs without issue until 2.7 With SRS the hitches happen continuously, I assume because srs is running passively in the background. With viacom they happen the instant I press the ppt button but only on the initial press. I had huge problems with my winwing hotas at first when it added polling requests to the export.lua, but never with srs and viacom. I'm at a loss.

Hi folks, just wondering if anyone else with SRS installed is having regular frametime stutters (every 1-2 seconds or so). I commented out the SRS entry in export.lua and my DCS went back to being smooth as silk. I think this might be the source of where a lot of people are seeing their stuttering performance improve by renaming their saved game folder (basically removing the export.lua). I've also tried deleting the overlay file to make sure that was the issue, but it made no difference. I initially thought that my issue might be viacompro, but I can leave viacompro enabled without any issues so long as SRS is disabled. it would be great to narrow down the issue as I don't think MP would be nearly as good without SRS. Edit: I just noticed that everytime I press the ptt button to engage viacompro, I drop 5 frames for an instant and my lua frametime jumps briefly. Looks like I have serious problems with DCS export.lua

I have huge FPS drops opening the F10 map on Syria and scrolling out to display the full map, it seems like the F10 map uses a ton of VRAM, I'm seeing spikes of 600-800MB going into Shared GPU Memory (this is bad)! This only happens on the Syria map and it seems as though something is going wrong here. I have a 3070 with 8GB of VRAM and DCS in VR demands all of it. I can tune my resolution and settings so that I sit at about 7.8GB of VRAM, but If I open task manager and watch my VRAM and Shared GPU Memory when opening F10, I see the jump in Shared GPU memory and then when I switch back to the cockpit all of the ground textures have to reload in from low LOD textures, so the F10 map by itself is basically forcing my GPU to have to unload terrain textures in order to display the map. Clearly something is wrong.

If you watch the video Jabbers will literally do the math for you, it's not calculated the way you think it is. It's a shame the PD/SS thing doesn't work, but it just flat out doesn't. Likely the improved performance you're feeling from tuning down your PD is outweighing the hit you're taking in fidelity, so it just feels better to you. On PD 0.5, as bad as the clouds look right now, BN was very clear that from internal testing, they scale *very poorly* with lower PD and the minimum PD recommended is 1.0.

Hey Nealius, from what you're describing, I think this is what happens on link when you run out of VRAM and windows has to used shared system memory (you should be able to see this happening in task manager). My 3070 has 8GB and I've experienced this exact behavior before and I had to tune my settings a bit to get rid of it. There are a range of factors that affect VRAM, and you can choose where to make concessions based on what's most important to you. Things that might be at issue: 1) Too much supersampling/PD, more pixels = more vram. I have in-game PD at 1.0 at the moment and oculus res is at 4864x2448 (1.2x) 2) OTT encode resolution too high; this relates to the amount of compression the image goes through and has a direct impact on VRAM. I went from, 3648 to 3100 here (2912 was a little too blurry for me) 3) Running oculus under openvr for the reshade; the new render mask only works for quest if you run under oculus, so you'll be rendering more pixels there. For me, the reshade is worth it. 4) In game textures at high (always leave ground textures to low for the moment). This can be an easy way to diagnose the issue, dropping textures down immediately frees up VRAM so the issue show go away. Personally I've kept the textures high and adjusted points 1 and 2. I was able to notice the massive framerate drops happening at a specific place in Syria, on the blackshark Megiddo to Haifa mission, I would point my Shkval at a certain place and every single time I would get single digit fps which wouldn't ever really recover and Oculus logs showed the encoder backing up. Dropping textures from high to medium immediately fixed it, so I new it was VRAM.

Just going to add my two cents here and say that the clouds in VR are the only thing in this update that has been underwhelming, which is ironic given they were the focus, but there's so much excellence in 2.7 besides. I'm using MSAA x2, reshade to sharpen, extra contrast, clouds on ultra, and my quest 2 in running at 4864x2448 and I've tried toggling all of these things on an off. Everything is sharp and looking great except the clouds which look very undefined and hazy no matter what type they are. Also, the aliasing on the distant clouds is pretty extreme, though I think that's a know issue along with the jitter. Overall, I've been having a blast with the new update since I nailed down my settings, but I've had to pretty much ignore the clouds.

Thanks mate, I'll give that a shot! Yeah, what I meant is that I'm running on higher settings so I don't have any frametime drops to play around with, so given I'm on the edge of smooth vs stuttery, it's easy for me to identify the small frametime cost of the sharpener, because I have no overhead. If I don't get the drops with the lite version, then I know it's tuned as well as can be. Once I have everything tuned as effeciently as possible, I'll drop some settings down so that I have some general overhead. It works! Thanks mate, that should help.

Fair enough, I've used the original one as well but I'm on the bleeding edge of performance and I noticed some slight stuttering from toggling it one and off and moving my head around, so I'd like to try the light version.

Have you gotten it to work Diamond? I tried using that dxgi.dll and the game crashed. I saw someone else say the same and I thought it might be an oculus problem.

Can anyone using quest comment on whether they got the light weight version (sharpereye) of this to run? When I try to use it my DCS just crashes at startup. Also, I've seen people say there's a way to flag DCS for steamVR without using skatezilla, can anyone remember how?

I get the mask if I run under oculus software but not if I run under openvr. This is an issue because I want to use the new reshade which only works with openvr.

Ok good, that give me hope that it can be fixed. I used a no steam openvr.dll that runs openvr without steamvr, but even after reversing that I still don't have the mask in VR, so I might repeat the process and start there.

Quest folks, I think I've diagnosed the render mask issue, it turns out that if I run DCS under steamVR that I don't get the mask but I do in Oculus software. In the above steps I think I reverted to oculus while trouble shooting the issue. When I went back into SteamVr I had the same problems. Can anyone else running steamvr for reshade confirm they don't have the mask? I'm wondering if the mask is absent or set to a wider FOV given that the quest has one of the smallest FOVs out there.

I had this same experience. I didn't even know a mask had been added until I saw screenshots of it. Not sure which of these steps solved it, but here's what I did: 1) Uninstalled all mods (used to use Kegetys) 2) Deleted FXO/metashaders in both saved games and for terrains 3) Deleted DCS/Bazar/Shaders entirely 4) Repair using full file scan and removal of extra files The mask only shows up in cockpit so load into a plane to check.

The MSAA mask works correctly now. The old default value of 0.40 covers most of the cockpit for me. The system resolution also works for the mirror. I don't understand the crop to rectangle just yet, it hasn't done anything when I've ticked it.

Shared GPU memory is different. Shared GPU memory refers to the case where your VRAM is at maximum capacity and the application has to dip into your system RAM. You never want to see this happening, and with a 3090, you won't. Rebar is basically about using PCIe bandwidth to maximize access to VRAM. Currently the standard is to access it in small chunks of 256MB as stated above. Rebar is designed to maximize VRAM throughput.