Jump to content

edmuss

Members
  • Posts

    1740
  • Joined

  • Last visited

Everything posted by edmuss

  1. It peaks at about 1030mv I think, I started at 825mv but it wasn't stable much above 1600mhz. I've run a few hours of DCS at +1000 memory without a problem, more testing required at higher though. Temps wise during heaven it's peaking at mid 70s core with memory a couple of degrees hotter. In DCS it's mid 60s to low 70s. This is with ambients of high 20s.
  2. I don't think it matters how much you initially lower the core clock in afterburner as long as the highest point in the curve ends up below your target clock speed. Once the whole curve has been offset downwards, select the curve point that corresponds with the maximum voltage you want to use and then drag that point back up to the clock speed you're aiming for, hit apply and it should then flatten the curve after the voltage and ramp up linearly before the voltage. Trial and error determines the sweet spot of performance by adjusting the clock speed and temperature by adjusting the voltage. In addition to this you can increase the memory clock for a healthy boost. Remember to check your stability with a benchmark, unigine heaven is a pretty good comparison to DCS (I think) and temperatures with gpuZ.
  3. Playing with the undervolt on my 3080ti (asus tuf oc), with maximum power limits set it will just about top 1920 when benchmarking but will be bouncing down to 1800 and even high 1700s quite regularly. Set the clocks to 1860 @875mv and she sits constantly at 1860 with occasional drops to 1845. If I try to push anything higher on core clock it crashes heaven benchmark dramatically, even if pushing the voltage up a little; I guess it must be the silicon limit. I've run the memory at +1000 without a problem and a quick test at +1500 was still showing performance uplift. Any thoughts on why I can't push the core clock higher? Looking at the 3Dmark results a lot of people are getting another 3-400mhz more.
  4. See I've noticed some juddering when slewing but I think that's actually reprojection ghosting from openxr as it doesn't happen all the time, moreso when the TGP is zoomed right in on highly detailed areas. I'll have a play with it
  5. Forgive me for being thick! But how would this manifest in DCS? Does it increase the maximum slew speed or simply the update rate which I pesume could give smoother slewing?
  6. Ah gotcha It's pretty simple really, enable the openxr for WMR performance overlay, this is the one with the coloured box - green for above refresh, blue for reprojecting and red for below refresh/not reprojecting. Essentially appCPU/appGPU are the times taken by the VR compositor to render the framebuffers, postCPU/postGPU are the times taken to carry out any post processing etc. (this includes the overhead for repojection). The Hz is obviously the output FPS. Remember that roughly 11ms = 90fps, 16ms = 60fps, 22ms = 45fps, 33ms = 30fps. To hit a refresh rate target add appGPU to appGPU and the result needs to be below your target. Worked example (not factoring in CPU): - Running the headset at 90Hz with reprojection on, you're tuning to hit the 45Hz render bracket (the best you'll get with reprojection). You're pulling 15ms appGPU and 3.5ms postGPU, therefore you have 18.5ms total GPU time. Your refresh rate target is 45Hz which is 22ms so you have approximately 3.5ms overhead GPU available before you start stepping down to the next refresh rate bracket. Note that appGPU doesn't include driver overheads which could be 1ms or so, as such it's best to give yourself a little extra headroom; with that said 45Hz vs 30Hz is pretty much indistinguishable so don't get hung on the 45Hz target - the jump from 22ms to 33ms is massive. If you miss the 30Hz refresh bracket then is will reproject at 22Hz, it's still smooth but get REALLY artifacty - unsuprising as 75% of the frames are synthetic and guessed! Openxr for WMR recommends a resolution based upon your VRAM capacity, the three back buffers with MSAAx4 applied should take up no more than 10% of available memory, for my 8GB 3070 this was 2480, the 12GB 3080ti is a touch over 3000 (can't recall off hand what it is). If you don't override the resolution on the openxr tools desktop app it will apply the calculation above, you can see the current resolution of the compositor on the second tab of the desktop app.
  7. The lower vram usage will help lesser GPU's somewhat more, but the big thing about openxr is the clarity gained by not needing to copy the framebuffers from api to api before spitting it out to the headset and the smoothness granted because it effectively works in the opposite way to steamvr. To the best of my knowledge, if you've missed refresh rate target (90Hz) then even though the GPU is supplying the frames faster than 45Hz, it holds the frame until the 45Hz tick is reached and the positional data is fed into the compositor; in simple terms it's only actually rendering at 45Hz but because the headset positional data is synced up it feels much smoother. The openxr performance overlays give you more granular information than fpsvr so you can read exactly where your bottlenecks are, have you not turned them on? Why run openxr at 50% when you're running steamvr at 100%? (it's better to state resolutions as it gives a defined value rather than a potentially arbitrary one). For reference I am currently running default recommended openxr resolution (calculated to around 3050 for 12GB I think), high DCS settings pretty much throughout and with reprojection it sits at 45Hz for the large part over Caucasus and Syria, it drops down to 30Hz over large cities like Beirut. I do have to wind the settings back to keep it high enough on Marianas but that's a given for any hardware pretty much. Since the recent runtime update the stability of reprojection is much better, still artifacting more than steamvr but until the code can (hopefully) be ironed out just take the rough with the (exceptionally) smooth
  8. Now go play with openxr and it gets better
  9. Yes if using steamvr, don't forget that there is a global and an application specific resolution; these mulitply if not set the same. So 100% global with 150% per app will give 150% total resolution, in the same way 150% global and 75% per app will give 112%. Assuming you're using standalone, I seem to recall that unless you add DCS to the list of steamvr games it won't persistently appear in the per app list and the option to override the per app resolution for DCS will only be available via the steamvr overlay whilst DCS is running.
  10. I would leave it all at 100% to start with to get a baseline of what your performance is looking like. More resolution = improved clarity (to a point) but less performance; there is a point of negative returns. Leave DCS PD well alone at 1.0, there are much better ways of manipulating the resolution, be that steamvr, openxr or pitool.
  11. I can't overclock my CPU as it's all locked down by AMD (5800x3D), I do run a 25mv undervolt on it to keep temps down and boost clocks high though.
  12. Have you read through my guide on tuning DCS with openxr? It's only really the first post you need to read
  13. I suspect that's the problem
  14. I've experienced the with steamvr in the past when HAGS was enabled, be worth checking to see that it's off
  15. Interesting. Is that due to the sunglasses filter or is it worse when without the filter? Check that you have movement damping (I think it is) set to zero on the inputs tab, there's a known bug that causes it to interfere with reprojection.
  16. Yeah, the reprojection on the latest runtime seems solid, still gets ugly at 22fps though Now to wait for the head positioning code to get as good as steamvr and artifacts begone!
  17. Have a read through Thud's guides for system tuning and do it all, no skipping steps unless they don't apply to your system. There can be a load of reasons why performance isn't good, it's easier to identify bottlenecks if you know the system is properly sanitised and tuned. Once your system is known good abs running cleanly then you can start to interrogate your frametimes and to where the bottlenecks are
  18. You're cheating, you're at 60Hz and above refresh rate most of the time aren't you? Can't get smoother than refresh rate.
  19. Pretty much, I use foveated rendering on quality/wide and that's about it apart from some post processing bits like world scale and lighting.
  20. I'm using openxr as it's far superior to steamvr for a number of reasons. No, reprojection is a technique developed by Oculus years ago to give the perception of achieving refresh rate when the hardware simply cannot do it. If the refresh rate isn't achieved then it renders at half refresh rate (45Hz) and interpolates synthetic frames in between the rendered ones. You can be getting 11.5ms frametimes (87fps) and the reprojection will be at 45Hz, you're still rendering 87 of the 90 frames every second. Reprojection has a computational overhead, typically this is 3-5ms. In order to achieve the refresh rate target of 22ms for 45Hz you must subtract this overhead from your appGPU frametime. Therefore in order to keep reprojection enabled you need your appGPU to be 22ms minus the overhead of 4ms which is 18ms. If you've locked the framerate to 45 (22ms) then reprojection will be disabled in steamvr (because you've missed the refresh rate target and it can't reproject below half refresh) and it will be janky as hell. In openxr in the same situation it will step down to the 30Hz (1/3 refresh rate) bracket (which actually does work incredibly well). The concept of locking the framerate with openxr is only for use when reprojection is off, in this instance you're relying on the vsync only to smooth head movements; rotations will be smooth, translations not so much until you get above around 60fps (below 16ms). The thought was why render more frames than you need to, save heat and energy; the sweet spot was found to be high 50s to 60s not 45. Personally I'd rather have the framerate unlocked at all times.
  21. 45fps is plenty with openxr, jagged lines is nothing to do with reprojection, that's aliasing. For reference I now run the G2 at 3100 resolution, high settings in DCS throughout with MSAAx2 + MFAA and reprojection unlocked and it's buttery smooth, no shimmer and no jagged anywhere. On Caucasus it runs at 45hz reprojection, on Syria it runs at 45hz and 30hz over the cities. By locking the frames to 45 and enabling reprojection your absolutely castrating the system because it needs to be above half refresh (45) for the reprojection to work in the first place!
  22. As quoted really, DCS will allocate all the VRAM available but I don't think it really uses much more than 10-12. Certainly the higher the resolution, the more you need. By my reckoning, the CPU is going to be pulling your frames down way before the GPU runs out of horsepower, it's just a function of how the current engine works. 5800x3D and a 3080ti now and I can get 90fps but with the same settings I can also get 50fps because the engine has dragged it down to the lowest common denominator. Better to tune to get a smooth experience and have improved visuals because you're not compromising on the GPU settings to attempt to crutch the CPU. edit: just for reference, I could run high textures on my 8gb 3070. Was it slower? Yes slightly, by about 2ms, but it still worked fine.
  23. My G2 with the V1 cable worked on 1 (of 14 available!) USB ports on my B450 motherboard and only via the USB A-USB C adaptor, all fine and no problems at all. Then I upgraded the 1070 to a 3070 and the headset just stopped working with a 7-14 error, 2 weeks of warranty left and HP sent me a V2 cable through; didn't fix a thing so after jumping through hundreds of hoops which included a fresh windows install on a different hard disk and testing on a completely different machine (at work) they replaced the headset. It's been absolutely solid ever since and works perfectly on the single USB C port on the motherboard. When they work they're great but some design choices could have been better made. For cable longevity I would thoroughly recommend not routing the cable over the top/outside of the strap frame as instructed, when the headset is raised it puts a really tight kink on the cable at the hinge point - in the order of about 25mm radius. I route it inside and below the frame (running just above the left speaker) with a generous amount of free cable before the anchor point at the back and even with 90° bend in the hinge it's only flexed in a 75mm or so radius bend.
  24. Once you've gotten your head around the settings, I'd recommend testing pimaxXR as that should give you access to the openxr toolkit along with a bunch of performance enhancements. I'm not sure if the openxr reprojection works with pimaxXR (not sure if it's part of the WMR openxr drivers or the openxr toolkit itself - if it's the latter then it should work I think). If it does with pimaxXR then that's a massive bonus for DCS as it allows you to reproject well below half refresh rate - 30fps reprojection is really smooth. Note that it requires DCS pd to be 1.0 only but there are resolution overrides in the toolkit itself that you can use to get much more granular control.
  25. Well technically openxr isn't a mod any more as you need to make zero changes to the DCS install, infact ED have actively made it so by removing the d3dcompiler from the bin directory. I would say that they're onboard with the usage of it although I would guess native implementation isn't likely with the current engine. I dare say that the new engine build will incorporate openxr natively Note that this is only my opinion and has no actually basis of fact as to which direction ED are going with the future vr engine
×
×
  • Create New...