Kreutzberg

I am also still seeing threads going onto the non-cached CCD with the most recent patches.

I'm not a big fan of the artifacts from Turbo Mode. But in any case, my OpenXR toolkit settings didn't change, yet I seem to have lost some performance!

I also note a slight performance drop since the most recent patch. I'm not quite seeing this much, though.

The only totally foolproof method is to pull up Resource Monitor and see if the other cores are listed as "parked." Even if it does that, though, just about everyone is reporting that in MT, some of the threads are on the wrong CCD. Game bar itself can be pulled up with Win+G, click on settings, and see if it's recognizing DCS as a game. I've had a lot of trouble with it remembering it, so I have my bios set to prefer cache, which works perfectly in ST. I also think that ST feels subjectively smoother in the current build.

My testing with a similar system (7950X3D and 4090) shows different results, with some improvements to frame times using the vCached CCD. I tested in Operation Cerberus North Mission 13A to make my results comparable to mjfrisby's data on page 6 of this thread: In that CPU bound scenario in VR (that's how I can measure frame times), I'm pretty consistently seeing about 3.5 ms better frame times with CCD0 only versus CCD1 only with Tacview on or off. That translates to something somewhat over 10 fps in the range of framerates we're looking at. However, DCS is currently pushing these types of performance numbers to 45 fps regardless. That might be causing some confusion if people are not seeing better frame rates. Even if locked at 45 fps or some other arbitrary number, better frame times give a buffer for more traffic or whatever. In any case, I do think the vCache is helping meaningfully in DCS.

I had the same issue. I set my bios to prefer cache, which gets the right cores working although the other ones are still not parked. In my ASUS motherboard, the setting is under Advanced\AMD CBS\SMU Common options

Based on some of the settings in this thread, I think you guys are not seeing uplift because you're in GPU bound situations. To ensure that you're checking CPU performance, you need to make sure that it is a CPU bound situation. A foolproof way to do that is set VR pixel density to 0.5. But if you're in 2D, then GPU-related settings need to be turned way down and load into a very CPU intensive map.

Based on some of the settings in this thread, I think you guys are not seeing uplift because you're in GPU bound situations. To ensure that you're checking CPU performance, you need to make sure that it is a CPU bound situation. A foolproof way to do that is set VR pixel density to 0.5. But if you're in 2D, then GPU-related settings need to be turned way down and load into a very CPU intensive map.

On my system with a Reverb G2 in Windows Mixed Reality and native OpenXR, I do still see the two threads going to different caches with the MT client, even with parking and bios set to prefer cache. The fact that it happens with my setup and not with your Varjo Aero might be very informative to what's going on! I also note that in CPU bound situations, the MT client gives quite inconsistent framerates with my setup, possibly because of splitting threads to both CCDs.

One other thought that might help with troubleshooting is that the behavior would probably affect any double CCD chip like the 7900X or 5950X in addition to the new X3D chips. So that might help even if the team can't get the newest chips for testing. My working hypothesis is that the multithreading is actually doing too good a job at splitting up the threads such that the system thinks they are completely unrelated processes that should be on separate CCDs. That might be totally wrong, though! I suppose leveraging the second CCD would have some advantages in addition to the disadvantages of cross-CCD latency. The second CCD has its own 32 MB of cache, for example.

For what it's worth, I can confirm the same behavior on my system with my 7950X3D. In the new MT version, one thread goes to the cached CCD and the other to the regular CCD. This behavior occurs even though Xbox game bar parks the non-cached CCD. I've even set my bios to prefer cache, and am still getting that behavior. On the regular single thread version, it all goes to the cached CCD as intended because of my bios preference (I'm actually having difficulty with Xbox game bar recognizing the single thread version as a game, unlike the OP's situation which is the opposite). Some of it might be Xbox game bar updates, some of it might be the AMD drivers, and some of it might be how the multithread version is working.

I was able to find the second tank. A bit challenging, but I suppose that's CAS. However, I couldn't get authorization to attack from the controller, despite trying multiple angles and getting right on the requested final approach course (I think it's 165). Are there other parameters to satisfy? I wound up having E-boy attack it. Is there a score penalty for that? I would up with 95, and I thought everything else was pretty clean (I enjoy the ATC scoring, by the way!). Thanks for the great campaign!

I was looking for the answer to this one, too. I've gotten into both CPU and GPU limited situations (verified with other tools like FPSVR and the OpenXR toolkit), and in both cases, the white line seems higher. So I'm not totally sure what it's telling me right now. I would be very interested to hear something definitive.

There are a number of exciting changes coming to the core DCS engine with the upcoming EDGE Engine, the Vulkan API and multithreading support. This should provide an opportunity to make a lot of improvements that would really help modernize DCS. Some of those changes are clearly happening, like DLSS. That's extremely promising. As VR player, the biggest immersion killer in my view is the relatively limited anti-aliasing. The 2D cinematic videos are absolutely beautiful, but VR is far less visually impressive. Hopefully, that's already in the pipeline to be included with the upcoming engine changes, but I haven't seen any discussions other than very old requests for TAA. Better anti-aliasing could take DCS VR to the next level!

This would be extremely helpful, along with some other core VR improvements. Hopefully, we'll see some of that with the upcoming Vulkan and multithreading improvements.

It looks to me like the SAR Daily Page Code Words from the briefing PDF and kneeboard were not included in the in-game briefing, for what that's worth. It's probably just a minor bug. I was struggling with the code words for North, South, East and West, and didn't realize there was an extra page in the kneeboard package.

Spoilers ahead for anyone who hasn't yet played this mission in this outstanding campaign: *** *** *** During this mission, our first salvo of SLAM-ER missiles was successful. I hit target 8 and Red hit target 4. When assigned to engage the Grisha, I launched my second SLAM-ER and was very proud of myself for being able to steer it onto the correct target. However, as it closed in on the Grisha, it was shot down by CIWS or other AAA from that ship (I can clearly see that is what happened on Tacview, and I suspected so as I lost datalink as it was closing in). I imagine that's just DCS's ever changing anti-missile logic, but thought it was worth reporting. Thanks for creating this campaign. Definitely my favorite so far!

For what it's worth, I was having this problem. I disabled the A-4 mod (the only non ED module I use except Tacview), ran the repair tool, and restarted my computer right before the mission and was able to get through it. It might help someone!

For anyone stumbling across this thread, the short/simple version of the repair tool resolved the issue. https://www.digitalcombatsimulator.com/en/support/faq/repair/ I suspect that an update would have done the same thing. It's probably some setting that got messed up from something, but I'm still not sure what that setting is!

A few days ago, I started noticing that my kneeboard is zoomed in to the top left quarter in VR (see image as well as a picture of what that page should look like). In regular 2D mode, the kneeboard images look fine. Is anyone else having this issue? I recently rebuilt my kneeboards using the kneeboard builder program, but this issue is now affecting everything (the one in my screenshot is from Raven One Dominant Fury anyway). So I'm not sure if the kneeboard builder had anything to do with it, but it is possible. I had another kneeboard issue last year described below. It eventually resolved itself with a DCS patch (I'm on open Beta). Kneeboard full page.pdf

Thanks! We appreciate it.

Here's a track I took of the issue just now on a quick case 1. I turned on ICLS so I could make sure I was not out of the glide slope. The IFLOLS was invisible before the break and only appeared late once I was in the groove. IFLOLS Dissapears.trk

I'm also seeing the IFLOLS itself disappearing, not just the overlay. I suspect it's the same root cause. It happens in both VR and 2D and with both the supercarrier and the default carrier as is stated elsewhere. There's got to be something with the underlying IFLOLS/meatball code.

Did you ever get a chance to put that together? I'm curious as to the scoring mechanism (and just getting started with this excellent campaign!). Thanks!

For what it's worth, the built in kneeboard is working for me with today's patch. VRK is quite powerful, but a bit overkill for my needs.