trevoC

What doesn't happen IRL is my head continuing to move while my site line is restricted. Considering that this has never happened to me in any of the DCS modules (I own all but 4) I can only conclude (possibly in error) that our setups are very different and this effects some but not others.

I agree 100. ffb is essential (iRacing is my best example of this, don't have ffb in DCS as I have winwing) I couldn't drive without ffb in iRacing... I'd literally crash going from ffb to non-ffb. On the other hand, I found out the hard way that once the gimmick of motion platforms wear off they are actually annoying (in driving anyway) as when it jolts you left and right it induces movement in the wheel that you did not want. I could not drive competitively with a motion platform and instead have gone with 6 shakers (one on each tire or corner of virtual car and one under seat and one on back of seat) Other than VR itself, ffb was the biggest immersion adder. Although it didn't add more immersion than VR it arguably is more important in racing sims. Really want ffb in DCS.

you can't restrict head movement and allow VR users to properly move around the cockpit and see gauges. It doesn't work. IMO, if you don't want to stick your head out of the aircraft, don't stick your head out of the aircraft. I can't think of a single time in 4 years of VR gaming that I've had my head clip outside the aircraft unless I did it on purpose. On the other hand. Games that restrict your movement prevent you from being able to move your head in a way that seems natural (e.g. to see a strange fuel gauge on the floor or behind you) without causing issues and many times preventing you from seeing it at all. Worse it creates weird clipping and jumping issues that are more immersion breaking than the top of your head being able to clip outside without you noticing it. Also, your head in VR when it hits a barrier stops moving even if you continue moving which is extremely immersion breaking when your head movements stop matching your in game movements. I can't imagine anyone who's ever experienced a "virtual box" for their head in any game wanting this feature implemented and can only guess that it seems good on paper but you haven't experienced it. It is the most frustrating thing I've ever experienced in VR, enough to not want to play that game, especially when it makes it impossible to interact with certain switches or gauges. You probably clip the aircraft (top of your head for instance) all the time without realizing it. You may look down and left and twist around in 6dof to see a switch in a WWii fighter and not realize that the top of your head is clipping some component in the model. If we limit this, you can no longer properly interact with that switch and the head movement doesnt match etc.... Its just awful IMO.

Its faster by a smidge on vCache. Ran above test without gains. Thought maybe the higher frequency cores might do better than the vCache for DCS. I was wrong. In raw performance the vCache was at least 2.5% faster or more depending on the scenario (never less than 2.5% more) which is actually more than 2.5% if you consider the vCache cores are slower to start so they more than make up for their slower clock speeds.

oh ok... "faster processing" is dependent on whether or not the software can take advantage of the vCache which not all software can so it can be confusing. right now (I've tested all scenarios... both CCDs independently, both with parking enabled and both with parking disabled... all cores available). At the end of the day, just leave the PC alone to do what it does. That is the fastest scenario which is nice because it requires no messing about. DCS with MT is not faster when disabling parking and allowing all 16 cores to be available according to all my tests on an x3D and all other things being equal would not be faster on a non x3D chip like the 7950x as I ran the test on only CCD2 (without vCache) which would emulate a 7950x (half the cores) but DCS doesn't use the extra cores anyway as it is not a true multi-threaded application.

No, the faster CCD is worse than the vCache CCD in all my tests by a few percentage points (around 2% slower if I remember correctly). Honestly though, its very insignificant. That being said, the moral is just let the pc do its thing. These are all fake videos for views. Many of them were posted before even review units were released.

I agree (re workarounds) as I've mentioned earlier. Even though MT looks like a mess (if you are watching cores park and un-park) it seems to be running on the cache cores (at least the main thread does) as my frame rates indicate the same performance as ST which parks nicely. My conclusion was the same... don't set affinity, don't disable CCD's, don't disable parking in registry, just let it be. It looks a mess but seems to be working. My cores jump around like.. some smart and funny analogy about something that jumps around a lot.

Now the "unfairness" lies in monitor size. 1080p on a 20" vs 1080p on a 50" Lets stick to rendering the environment as close to reality as possible and let the cards fall where they may. The only methods of easier detection that I would support is improvements in the sim itself (like HDR) that would in turn help improve this. I think the first problem is that people don't realize how difficult it is to spot aircraft moving at speed in the sky IRL in the first place. Its why we have systems that prevent mid-air collisions. Because a passenger jet can sneak up on you. If pilots have trouble seeing passenger jets that they are close enough to hit, why are we trying to improve the visibility of an f-16 at 12 miles?

Agreed, sort of. Not necessarily favor better hardware for the sake of better hardware, but just be realistic and the purchase of better hardware will garner you advantages. I knew what you meant though, just making it clear. Creating some type of "fair" system for aircraft viewing distances is the equivalent of capping my frame rates to 20 fps because my 4090 gives me an advantage over another user. Thats insane. I view any type of balance of power for "fairness" just as insane, especially when you have to create a system that makes it less realistic to do so. This isn't competitive COD. Its meant to be a simulator. If you want fair, play chess. (not directed at you SharpeXB, just a comment)

even 1 pixel is too big. It garners an advantage for those running lower resolutions. Imagine (exaggerated for effect) a 50" screen running at 720p... apple sized pixels... you can see a fighter as soon as it appears. On the flip side if you are running super high res 8k, you can't even see a single pixel. This makes those who are playing competitively who are running a lower res monitor have an advantage. On the flip side if you just render aircraft at proper distances, those with higher resolution monitors in theory have an advantage, but I believe its the better system as although a single pixel on a low res monitor is less pixels than 4 pixels on a monitor with double the res, if the monitors are the same size the viewable aircraft is the same size. But then of course those running larger monitors have an advantage over those running smaller monitors. There is NO SOLUTION as long as players are buying different hardware. Its the whole idea behind homologation in motorsports for instance. There is no way around this unless you have standard hardware which would be ridiculous. Like everything else in this world (including all games as you can gain an advantage with buying better hardware), people can gain an advantage with purchasing better hardware. IMO, eff FAIR. Make the sim realistic (no sprites, proper render distance and they appear when they appear). If you are focused on some advantage for MP, then go nuts. I'm focused on a realistic experience and know that as in real life, some advantages will exist for some.

Best for whom? Thats the problem.

Agreed

Its not a possible task to make this infinitely fair. One method begets the next and no method will be all-encompassing. You are just going to have to live with that fact.

Yes. I only mention averages because I'm giving an overview in a new thread. I'm not about to go down the rabbit hole (pages) of information available in other threads. Just wanted to help others in this one. Take it or leave it. No idea what you mean by not making excuses....

the short of it, (I've got over 20 hours of logs with 3 different track files running 3 different scenarios on a 7900x3D) don't disable anything or try to set affinity or any other BS. There is little difference running DCS on vCache anyway, but there is a difference (very small) That being said, it seems to be running on vCache cores (even though it looks a mess) e.g. my cores are jumping all over the place, parked then not parked, sometimes the wrong cores parked etc... After running tons of test on ST and MT, just let it handle it. There is a very small increase in vCache over non vCahce (about 1.5%) so don't worry too much. Unfortunately DCS doesn't seem to benefit near as much on vCache as I expected. MT however is a huge benefit (vCache or not) in certain scenarios. MT has about a 4.5% gain in scenarios that don't benefit much from MT and 10-40% (22.5% average) in scenarios that do benefit from MT (like plazma torture track) After tons of fudding about, don't disable parking in registry, leave it enabled, don't disable CCD's in bios, leave them both enabled. Try to ignore the crazy parking back and forth that you might get in MT... it looks a mess but runs faster than dozens of other scenarios I've benchmarked. Hope that helps. AMA

MT isn't a magic bullet. In an instant action or campaign with few units you may see little to now improvement. (4.5% on the track I use with Huey on Marianas) That being said 10-40% (22.5% average) on a map with lots of units (plazma torture track) If you are not seeing MT improvements its most likely because you are not flying scenarios that take advantage of the seperation. The real trouble DCS experienced before MT was getting your sim dialed into lets say 45 fps and then playing a mission where a bunch of units spawn and bring your rig to its knees. In MT, you won't get more than 45 fps (whatever your baseline before was, 45 is just an arbitrary number for this example) but when tons of units spawn instead of bringing DCS to slide show town, it will potentially maintain 45 or only drop to 35 for example. MT is not a magic bullet for more frames but more a fix for when you would dive to slide show territory.

There is no need to do this anymore. DCS supports openXR now.

You couldn't have possibly expected an actual 2 week release for this.... Personally I'm not expecting a 2023 release for this. I'm just as excited but the trailer just means that ED will develop it, not that its about to drop.

Basically you can go high/ultra on all settings. The only ones I scale back to prefer higher frame rates are Water>Low and visibility>High (instead of extreme), all else is maxed out except SSAA SSAO and the other one (off the top of my head can't remember) but they are all in a row are off. You could easily max out most things but then you will find yourself dipping below 45 fps sometimes. I prefer the above and operating in the 60-90 fps range (75 ish most of the time)

I'll have to check the logs on frame times but I've never seen them this low. In DCS when it locks to 60 fps (not GPU or CPU bound) the frame times are a line across the bottom like they aren't registering. when they do register, the graph is the bottom 1/6 of the chart. I haven't run a single test where the frame times were of any significance whatsoever. Major improvement here. I'll have to look back to see how much less or greater they were between vCache core and non, which I'll do if I can easily find the video and logs. (they really started piling up)

I'm getting extremely low frame times across the board. Didn't install tacview this time around (I think from your testing from another thread). Interesting you mention locked at 45. I am experiencing a strange issue where it seems to lock to 60 fps or 90 fps (75 also I think). Either way, it will act normal (by normal I mean floating fps number up and down constantly in the 70's range, then all of a sudden it will lock at 60 fps and you can see that neither GPU or CPU are being fully utilized so there is room to jump back up to 70-80's but it won't..... It does the same at 90 fps for some reason, just not as often. Then for no apparent reason it unlocks and the fps floats around again while the GPU runs full tilt.

I believe its just the fxo and metashader foler you need to delete between testing between ST/MT.

Thanks chev, I'll share my latest insights... another dozen or so tests. These tests I wanted to see how much of a difference vCache made in my setup and if parking the cores at all made a difference or just prevent all cores from parking ever. For the vCache difference, I used DCS ST as there is some weird behaviour with parking cores on DCS MT that I haven't resolved yet but some of the tests are starting to paint a broad pictures at the moment. First, the difference between DCS ST running on CCD0 or 1 is negligable (less than 1.5% in favor of vCache). That being said, it always seemed to be in favor of vCache. Also remember that the vCache cores run at lower speeds, so considering they always performed a bit better (margin of error a bit), I conclude that they are actually doing something. If they were not doing anything I would expect the same reduction in performance than the chips are reduced in speed which isn't the case. vCache although not some magic buillet in DCS unfortunately (as they are in some games) doesn't hinder the performance at all by running on the slower chips. vCache seems to make up for the difference and then some... a little some, but some. I consistantly got 1-1.5% more performance on the vCache cores. I then wanted to test in MT DCS if not parking any cores at all would be better than allowing cores to be parked. This would allow the entire chip to be used by DCS as it saw fit. What I found confirmed my above results also when compared to a prior set of data that was just MT runs. When the core parking was completely disabled via registry, it would just act like a 12 or 16 core chip (depending on your model). Of course the first 1/2 run slower so this would absolutely come into play. What i found was DCS got assigned to the faster cores by default which gave me about 1% less performance (also sort of confirming the above results). I didn't find it running any faster on plazma torture map than MT with parked cores enabled (even though they park very weirdly). I'm guessing even though DCS can use multiple cores, its not using more than 6 cores at the moment enough to disable core parking and have more cores available. This was my guess in an earlier thread months ago as I doubted that DCS would be a true multi-threaded application. I've concluded from these and prior rounds of tests the following so far. Obviously this can be different depending on your situation. -MT DCS is worth running as I saw gains of 4-5% in small scenarios like instant action and 10-40% (around 25% avg.) on plazma torture map. This is what ED said it would do so Its a result that matches the expectation. I have no further desire to test this when receiving the expected result. -vCache is doing very little in DCS. It does do something, so if you have an X3D chip I wouldn't go to lengths to disable parking cores, but from my tests I wouldn't be running out to get one either. I'm betting there would be very small differences between the 7900x and 7900x3D in DCS. Obviously if you are playing other games this might be a factor worth considering as the x3D chips are wildly different across games and much more successful with others. -Disabling the parking of your cores does not yield positive results, so I wouldn't bother. -Core parking works perfectly on ST DCS but seems to work a little strange in MT. That being said, the numbers seem to state that the MT version of DCS is being run on the vCache cores even though windows is reporting otherwise sometimes. Even though the MT core parking looks a hot mess, the numbers confirm that they are consistant with being run on vCache properly and Multi-threading itself is a benefit. In the end, I'm running the MT version of DCS and ingnoring the mess that is being reported by windows, logging tools, DCS etc... It is garnering better results. ------- I still want to test a number of items including GPU scheduling settings and other windows optimization settings but I wanted to do this with a baseline that would be more consistant with what I'd be using going forward. That is now DCS MT so stay tuned and I'll post my results. I did record all this, but its hours and hours of boring footage that I'm not interested in editing. If you are interested in seeing some of it I could probably just upload it raw but you wouldn't have access to the logs in the background that I used, just the onscreen data. -------- Hope this all helps someone, feel free to ask me any questions. If i know I'll answer.

This is my experience more than the other. To each their own. Clearly there are wildly different experiences based on all types of variables.

With MR I see a slideshow because the artifacts pull me into experiencing the display rather than allow it to fall back into the experience as it does without MR IMO. I have a high tolerance for low frame rates, others do not. It absolutely matters IMO and I was responding to someone who was asking how people don't get sick without MR on. Its because there are different tolerance levels of this.