Woona

Wonderful. Just ordered a right-angle cable; would've been SOL on delivery if it weren't for this heads-up. Thanks!

I've been wondering about precisely this for the past few days. Thanks for posting. Am I correct that the USB port type on the back of the 16EX is USB-B? Second, I've read several people with the 16EX write that the side plate can block the mounting holes on the corresponding/left side of the throttle's base. Did you experience/solve this issue on the MT mount? Thanks again.

I tested out SMAA when this first came out. For SMAA to be of real value, I had to combine it with FXAA. This was in the original version of the injector and the two did in fact run concurrently. They complimented quite alright for me at first glance. However, it was still visually less consistent (shimmer on buildings persisted as if there were no AA, and building/runway shimmer is the #1 reason I use AA in DCS) and gave me the same or worse performance than just using MSAA 2x after testing, further emphasizing from a performance standpoint that both were doing something. This was of course in 2.5.6 but I'm assuming MSAA's function hasn't changed between that and 2.7. If you're not too worried about building highlight shimmer and can't afford MSAA, then SMAA as-is might be a good middle ground.

So essentially 1) rename dcs.openbeta to dcs.openbeta.old 2) run complete repair on DCS using the repair tool 3) copy over old files as required I'll try to ask friends to do that when they see it break (knock-on-wood that my MSAA doesn't break once again). Thanks for the response, really appreciate that.

Could you elaborate on the renaming trick/link to it? Contrast Adaptive Sharpening, an AMD-developed tech that allows sharpening both for 2D and VR. It's really a must-have for me in DCS VR:

With VRAM being a sacred resource for many running DCS, being able to get the sharp cockpit without the VRAM usage of subjectively negligible ground texture differences would be a super help - not the least for those not lucky enough to have a ReBAR-capable card or one with large VRAM capacity/bandwidth. Great idea.

3080 here, my performance in vanilla 2.7 is as good as 2.5.6 with the most performant shaders. I don't think we can accurately or consistently blame VRAM factors on this one, I see others with 20-series GPUs doing both better and worse. I'm not sure what's causing the inconsistency but I'm sure the devs are on top of it. Regardless of what's around you, it should always be black.

I think we should end the conversation on Vsync Fast vs Off with this post so we don't end up getting a hijack-situation, unless someone has a ReBAR addition to it. Sorry to kick it into a weird direction all of a sudden. I just ran my Batumi benchmark with my headset, switching between the two. My experience kinda cements the results above. By going full aft, pointing to the sky, then quickly jinking down towards Batumi, i'd induce a stutter. Sometimes a stutter would just happen. I was not able to induce it on any of my Vsync Off runs. However, my Vsync fast setting bumped up my refresh to full rate more often. I fly with my Index locked to 48fps anyway (fellow Index users take notes, it's awesome) so I'll take the decrease in microstutters any day. And here's the kicker: My global default was Vsync Fast, and I haven't touched my global defaults. Might poke around other people's DCS VR systems later and see if theirs is the same and if they experience the same decrease in stuttering on Vsync Off - if they were on Fast at all, of course.

So slightly off-topic but I thought it'd be worth a mention, although not worth a thread. I don't know if it's the enabling of ReBAR or the update to 2.7 that's done this, but just now I was running the good ol' NVCP tests to make sure nothing in the Nvidia Control Panel had changed. As usual, most everything didn't work and is a waste of time, but one thing that used to give some deltas is now giving yuge deltas. Check it out. Wish I'd checked for this on 2.5.6 but I'm not bothering rolling back just for that. One has under 1/3 the missed frames, the other higher averages and half the frametime... I think the only way to really pick here is actually trying it out in the headset. Do any of you have experience between these two settings in NVCP?

For the record I'm on an Index as well, and my mask is black. It sounds like you've got something unsual in your build. Give DCS a complete scan repair, including scanning for and removing extra files. Remember to backup any mods you might cherish. I appreciate the notion but all I did was register conflicting files until the build was functional. Kegetys has done all the real work here so I'd rather keep it in his name. Just don't wanna inadvertently step on anyone's feet here.

Hi, as Shaun mentions, shared GPU memory is not indicative towards utilization of resizable BAR but rather indicates a usage of system memory by the GPU in the case that your GPU's VRAM is fully utilized. As you can see in your screenshot, that is also why it says 64GB - unless you have a GPU with 64GB of VRAM, of course. This tech predates even PCI-E 4.0 by several years. https://www.extremetech.com/computing/251763-microsoft-shares-new-details-gpu-monitoring-capabilities-windows-10-fall-creators-update#:~:text=Shared memory represents system memory,memory used by that process.

Performance in 2.7 really is astounding. Haven't seen this good vanilla VR performance since 1.5. For the hell of it, I registered which files were conflicting and snipped them out after necessity and gave it a run-through. Basically just a duct taped together version of the 2.5.6 VR shaders because insomnia. Averages from Nvidia FrameView benchmarks look like this: Validated with OCAT for frametimes (note FrameView and OCAT measure FPS differently, hence discrepancies, FV is more representative for VR framerates): Nothing to write home about, but hey, it's free real estate. Seems like the framerate has an easier time staying high granted the balance between 90th, 95th and 99th percentiles, further confirmed by the higher average FPS despite similar maximums and 8% discrepancy in minimums. I've done minimal testing but attached it in case someone really wants it I guess. Shaders IC.rar

Here's hoping Nvidia doesn't make it lock it down to something at a lower level, but listens to their customers and gives us the option to manually enable it for individual games. Maybe nothing changes at all, that'd be OK too.

@ShaunX More data is always good, thanks! That's a 14,05% uplift (121 -> 138) in 99th percentiles. I'm also experiencing lower temperatures on my GPU and CPU, interestingly. I thought it was just a freak coincidence every time but if it's happening to others as well, I guess there's definitely some increased efficiency going on here. I'm starting to ponder if this should go in the 2.7 Optimization Guide. I just also don't want even a single case from a poor guy who bricked a single-VBIOS 3000-series card or whatever. That'd break my heart. But there's obviously performance to be had, so far as we can measure, ReBAR or not (until someone provides a way to check on a technical level if ReBAR is truly working, anyway). Edit: Speaking of which: I heard from LTT recently that Nvidia told him ReBAR is simply an enabled profile for the individual games. Unless they're specifically hiding technical details, this method of using NPI and enabling ReBAR flags would make perfect sense. But alas, I don't have a way of actually verifying other than our measurements.

Oh shoot, you're totally right. I guess it's about right then.