edmuss
-
Posts
1740 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Everything posted by edmuss
-
Only as a 2x8 and 2x4 configuration. Generally mixing ram sticks isn't advisable unless you can match the model numbers and memory type.
-
As a test, try running this in the background, it will flush the RAM out when it hits a threshold. When I had 32GB it would quite consistently drop the usage to 19-22GB which gave plenty of overhead when it got busier. https://www.koshyjohn.com/software/memclean/
-
They will work fine, but the V1 versions also work perfectly https://uk.webuy.com/product-detail?id=svrhtcvivbasstac&categoryName=vr-tech&superCatName=electronics&title=&queryID=8da7060333fc6a8bdfc1cbfe35dd1445&position=2
-
The lasers are disabled with touch enabled, I think with touch disabled they just show up as a cursor now. Not sure when that change was implemented as I've never used the pointers.
-
Blimey, I've not had to copy that over in over a year I wonder if something has been deprecated with all the recent updates to leap implementation in DCS?
-
How are you running handtracking in DCS? The option on the special tab is purely for an external leap motion sensor running the gemini drivers as far as I'm aware.
-
If you want it to run in an openxr environment (assuming that you're using open beta) then the leap motion drivers need to have the support enabled. It's supported openxr for the last couple of years though. Is this with a leapmotion 1 or 2? Which version of the gemini drivers? I've not updated the software for mine in the last month or two but it works perfectly for me with 2.9 and activated from the VR tab.
-
Openxr support needs to be enabled if you're using openxr, I think 9/10 users probably are now.
-
I don't know what pimax does with the hand tracking, pretty sure it's ultraleap hardware but I don't know what software it's running on. Have you tried with the ultraleap Gemini drivers?
-
Jabbers issue isn't the one being discussed in this thread though, that issue is completely different to the VRAM overallocation. edit: a couple of comparison screenshots, mi24p instant action weapon range on Syria. First is high textures, second is medium textures; both are utilising Taz's optimised textures. GPU has 12gb onboard. Check the usage of ~8gb and the horrific graph spiking compared to the usage of ~6gb and the perfectly smooth graphs. Both are completely within the budget of 10-11gb set by DCS. It's VRAM overallocation causing the runtime to fall over.
-
If you're buying new get the 2, if you're a skinflint like me then get the 1 cheap on ebay On the whole the 1 has sufficient tracking envelope for most of the controls that I need to access in DCS, some are difficult to manipulate (due to tracking occulsion or physical constraints of the desk/walls) and for those the head slaved cursor comes into play.
-
Been using leap motion for the last couple of years and the 2.9 update made BIG leaps and strides, ED actually implemented nearly every feedback suggestion from the forums and it's become really good. I use the leap hands mainly for forward controls (MFD/UFC) but for startup in the hind/ka50 there is feeling like flicking a row of toggle switches up sequentially Just need the 3rd party devs to implement it!
-
Managed to do a little more testing last night with mixed results, the times that the VRAM budget stayed below 11GB (generally 10.5-10.7) it was all good, however it wasn't consistently keeping the budget reduced and did still occasionally push up to the 11.3GB which would then cause the overflow. Forcing the cockpit texture reload (F10/alt tab till flushed/alt tab/F1) would drop the usage back to acceptable levels. Take away is that it's inconsistent and isn't a reliable fix although it does appear to do something (likely not intentional, possibly placebo/situation dependant). I still reckon reducing the budget to GPU VRAM less 1.5GB would be prime trial to solve the issue.
-
That was my nominal thinking on it. The CUDA thing had me really sceptical about it at first, but I was pleasantly suprised with the quick initial test (note that I've not been able to test any further yet). Perhaps the CUDA in this case is relating to the CUDA cores (as in the hardware cores of the GPU) rather than the API? If indeed it does work and continues to work, it's still a sticking plaster and shouldn't need to be relied on
-
Truth be told, I don't exactly know, however initial tests were positive in my use case. DCS will still overallocate if your usage surpasses budget, logically with no sysmen fallback it may hard crash DCS. What this did on my system was reduce the allocated budget by 800mb (11.3gb down to 10.5gb with fallback off) and allowed the VR compositor to continue working whilst using much larger percentages of the allocated budget. Previously I would get the issue at >7gb usage with 11.3gb budget, in my brief testing I saw 9.5gb usage with 10.5gb budget without the massive stutter issue. I have no doubt that if I went over 10.5gb usage it would be horrific This does nothing to manage VRAM load, you have to do this yourself, I use Taz's optimised textures and that generally is sufficient with my 12gb GPU to keep things smooth. As to why the VRAM budget changed, I'm not sure, I would hazard a guess that DCS will set the budget based upon the VRAM available to the GPU. If with sysmem fallback enabled it may be that the GPU is telling DCS that it has access to the system RAM (indeed windows task manager states that I have 12gb dedicated VRAM with 26gb total available) and it sets it accordingly; perhaps with no sysmem fallback it's seeing a hard limit of 12gb so drops the allocation a little?
-
New Patch 2.9 really bad Visuals (blurry) with the Pimax Crystal
edmuss replied to Nedum's topic in Virtual Reality
If you've applied DLSS, DLAA or TAA then you will get smearing unless running at very high resolution. I see practically no smearing in the aero but then it's so much higher resolution than any other headset bar the crystal. Almost a double edged sword, DLSS in VR, it can help the lower level hardware with good performance increases but it hurts them so much more if running at lower resolution. -
Just updated to latest nvidia drivers, set this accordingly to prefer no sysmem fall back and booted mi24p Syria weapons range, straight load to cockpit 9.5gb usage of 10.5gb budget, smooth as you like, no overflow and no massive stutters! It was slightly laggier to load into F10 map but once loaded it was all smooth, certainly before I couldn't fly with 9.5gb usage! I've not tested it extensively but it initally seems to be a good workaround, excellent spot @desolunatic, go test it people
-
MSAA takes up VRAM, by turning it off you may have moved yourself slightly further below the threshold for overflow. The F10 map isn't the root cause of the stuttering, it's just that sometimes switching to the F10 map appears to perhaps create a memory hole which causes the overflow. From my further testing I've correlated it to VRAM overallocation
-
I'll give it a go later and see if it makes any difference
-
You may not utilising enough of your VRAM budget to push it into overflow, you need to look at the usage/budget values in the expanded performance metrics. Increase your settings until you're consistently using 75-90% of the budget and then see if it happens. Because of the narrow bandwidth of the 3060 this will likely mean that FPS will have dropped a fair amount.
-
Happy to try to help out with specific testing if required Fully appreciate that it will not be as easy to implement as it is to type, if this can be looked at though I reckon that it will potentially solve one of the longest running issues in DCS VR - it's been in existence for at least 3 years to the best of my knowledge. Can anyone replicate this issue with WMR in 2.9? I suspect that the fix instigated by mbucchia that locked the compositor VRAM will also negate the problems experienced here; if that's the case then it's a very quick and easy elimination. edit: @Special K a few people have tested this in WMR without suffering from the performance tanking but still running at 75-90% of VRAM budget. This just reinforces my theory about the overallocation of VRAM as the WMR openxr runtime has had a portion of the VRAM locked exclusively for the VR compositor.
-
100% agreed, it's only a temporary sticking plaster to mask the issue; the memory usage is the memory usage. However in VR there is a specific scenario that makes it uplayable and as I mentioned a few posts back is identical to the VRAM allocation preventing the compositor from operating correctly. What I experienced last night whilst doing some testing with other settings: - Mi24p Syria weapons range instant action. Load to cockpit and VRAM usage jumps immediately to 9.5GB and I'm suffering from the overflow issues described in this thread (spikes in CPU/GPU frametimes graphs and FPS all over the place, zero smooth head movement). F10 to map, VRAM usage remains at 9.5GB. Alt tab for a few seconds and VRAM flushes down to 2.5GB, alt tab back in. F1 to cockpit, VRAM usage jumps up to 5GB. Perfectly smooth FPS and frametime lines, perfectly smooth head movement and able to fly normally. Yes the issue is exacerbated by low VRAM, I only have 12GB, but if usage within DCS stays below 7GB generally I don't suffer the problems outlined in this thread. Please can it be tested with a reduced budget? My budget is set at 11.3GB only leaving 700MB till overflow, if I'm only using 5-6GB VRAM then I'm more than happy for the budget to be set at 10GB for example. I can't tell you the actual amount required above the DCS budget to allow the VR compositor to run unfortunately but a series of trials/testing should be able to nail it down pretty quickly
-
Unfortuately you're not going to have a great experience with the 3060 unless you're looking at valve index/riftS/WMR gen1 headsets, however their resolution and clarity impedes the reading of stuff in the cockpit; definitely below par for driving a G2. Additionally the 4 core CPU is likely to get swamped pretty quickly now with the MT engine. Realistically to have a decent VR experience with the G2 you should be looking at a 3080 upwards and even then you need to make compromises with resolution and some settings. When setup right it's a massive thing, I've seen uplifts of close to 100% with the aero over pure stereo rendering. I have tweaked and tuned it to achieve these figures though.
-
Unfortunately no, this is nothing to do with windows page file, this is the GPU being forced to use the comparatively slow system RAM (and the data transfer limitations of where it is in the system) instead of the very fast VRAM that's onboard of the GPU. Having more VRAM will mask the issue so all of the 16GB+ GPUs I think will struggle to see the problem. You're not using WMR with the quest as it's the occulus runtime; can only hope that a resolution to the problem is actioned by ED, all being well there should be a fix in the works but it's been an issue for the last 2-3 years at least!
-
I have been doing more testing on this, not specifically to combat the F10 map performance tanking (although that may be linked) but to try to investigate what's causing the performance to tank in the first place. The issue is definitely VRAM related, but I don't believe that it's due to a specific lack of VRAM capacity, more the overallocation of VRAM. During testing I have seen performance regularly tank with the frametimes spiking all over the place, this is with around 7GB of VRAM used (according to the DCS metrics and corroborated with MSI afterburner), however DCS metrics are stating a budget of 11.3GB (using a 12GB 3080ti) and MSI is showing a total usage of 12.1GB. The VRAM is being paged to system RAM despite the fact that only 60% of it is being used. Going back around 18 months when the use of openxr in DCS was becoming more widespread via open composite, I had discovered a similar issue occuring that was causing performance to tank if reprojection was enabled. This was investigated by @mbucchia who identified that it was an overallocation of VRAM that was preventing the runtime from being able to function correctly. At the time he was able to make an alteration to the WMR openxr that marked the compositor memory as locked and this completely fixed the issue 100%. However this workaround is not really the correct way of doing things, it should be DCS not overallocating VRAM rather than each VR vendor making changes to their runtimes to accommodate. I don't know if current WMR users are having any issues with this VRAM overflow bug (for want of a better name) or not, 24GB cards are not going to be affected so it needs to be tested on specific hardware. @BIGNEWY could you please pass this information forwards to the necessary team and see if the allocation of VRAM could be reduced in order to allow the VR runtimes to run the compositors correctly?
