Jump to content

fierceBeaver

Members
 View Profile  See their activity

  • Posts

    108

  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Posts posted by fierceBeaver

    [DCS 2.5] HTC Vive steamvr reprojection doesn't work properly

    in VR Bugs

    Posted · Edited by soundslikerust

    HTC Vive steamvr reprojection doesn't work properly. I.e. Ka-50, caucasus map, high settings (>11ms frame time), instant action, first mission. When on pause look at console and try to move your head left/right and forward and back - its stuttering like never before:helpsmilie:

    Maybe its tied to shadows it feels little worse when flat shadows are set i'm not sure. When looking outside (F2) (still >11ms) it seams working better.

    [DCS 2.5] UI Layer toggle VR zoom Important

    in VR Bugs

    Posted

    There is as well something wrong with the zoom, as the head movement is something totally weird that cause terrible experience. Needed just to try out that zoom feature as I haven't ever used any zoom feature in DCS and now I will keep it away.

     

    I would instead that like to see the cockpits to be re-designed VR in mind, simplifying textures, enlarging buttons and switches and cauges and making all just with higher contrast so it would be easy to see cockpit elements without any zooming or leaning forward. All texts should be readable from default head position etc.

     

    Yes it's a fish eye from different FOV i think, it's preatty bad..:helpsmilie:

    [MERGED] DirectX 11/12, OpenGL, VulkanAPI Discussion

    in PC Hardware and Related Software

    Posted

    I see you're using Oculus. Can you run DCS with steamvr or you run it with oculus binaries?

    (of course i'm not asking about installing DCS on steam - just using steamvr binary for starting VR game I heard that some games use it for oculus).

    I use steam tool to see frame render times for CPU and rendertimes for GPU. You can find it in the steamvr settings. If not you have to find similar tool in oculus environment.

    [MERGED] DirectX 11/12, OpenGL, VulkanAPI Discussion

    in PC Hardware and Related Software

    Posted · Edited by soundslikerust

    to #2: I think with recent CPU's up and beyond 5GHz we have more a GPU problem.

     

    Tho your point is still valid and I have tried to explain this myself and must admit, your words are far better: "...you just don't make it in time".... THAT is when 5G+ solves your problem, imho. Those new Intels may be flawed, but they are ridiculously fast and have a low latency themselves, actually the 7700k had better/lower latency on the RAM then 8700k, 40ns vs 48ns.

    Some recent chipsets are twice this value, AMD for example. That may explain the gap in gaming to some extend. 40ns or 80 or 100ns is quite a difference if you need to access it many thousand times a second.

     

    Input lag is another factor and of same importance. you will loose every millisecond you gained if you use the wrong gear, remember the chain philosophy, the weakest link.... !

     

    I can't render 90Hz on lowest setting because of CPU with 1080ti waiting for it. Can't measure 8700k but between my 6600k 4.7GHz and 6600k 4.0GHz there was less than 1ms of difference and all cores was about 40-50% utilized. We're looking at DCS - there is more than 24ms CPU overhead in VR to render 90Hz on high settings and 11ms time frame... in other words more than 24 times this 0.7 GHz. I would love to see CPU frame time below 11ms on high settings on 5.5GHz but I have no delusions. It would have to be 10GHz based on my measurements. Or some optimizations but looking at optimization progress from 2016 tests - 2 years ago i'm bettin 10GHz intel will be first there...

    2 years ago in this analysis some users found that there is minor impact of todays GPUs for stuttering problems. My measurements show the same.

    If you can please measure your 8700K - we would see how much better 8th generation CPU is better from 6th. I will link it on forums. I wouldn't count on miracles tho...

    2018 Hardware Benchmark - DCS World

    in Game Performance Bugs

    Posted · Edited by soundslikerust

    EDIT: Updated Facts and added DCSv2.5 bench. o7

     

    I want to continue huge work done here but also focus not on fps but on frame latency.

     

    Like most of you already know frame latency/frame render times are much more important than pure average fps. With all stuttering and inconsistencies of DCS engine and DCS maps it's frame render time most important statistics. For those who play DCS with Vsync because they don't like stuttering or play in VR it's even more important. For VR every frame has to be pushed by CPU in 11ms time window (90Hz) and for 60Hz monitor it has to be prepared in 16ms window. If not - this particular frame won't be rendered and fps will be cut in half to 45fps(VR) and 30fps(60Hz monitor vsync). Of course i'm omitting g-sync etc.

     

     

    Facts to be aware of:

     

    1. Fast frame render times and good frame consistency is what people perceive as a sense of flying and flying speed. That's why BMS is regared as very good at it - it's just old as hell and has very low frame latencies on modern hardware.

     

    2. In case of VR or Vsync you can have CPU utilization at 40% and GPU utilization 100% and be CPU bottlenecked. It just means your CPU can't push all the data for a frame in 11ms - it doesn't have to be utilized 100% for that. It just will not make it in time.

     

    3. People tend to think that if CPU is 100% utilized on every core Game engine is well optimized - it's the opposite when it's done with work on 30% utilization and waiting for new task it's much better optimized.

     

    4. Yes DCS Game Engine (mark difference between game engine and graphics engine) is CPU bound not GPU bound (less truth in new v2.5 in non VR scenario). Of course you can throw at it 5x supersamplng, 8x MSAA, 5x DSR and much more and you will push the GPU to it's limits (hence 100% GPU utilization in the point 2 above). But when you set lowest settings and start mission you can be restricted by your CPU power because those 11ms and 16ms restriction and it will bottleneck your system.

     

    5. It's highly possible you will have average 70fps with those frame drops and stuttering because fps measurement is just a statistic - temporary fps or average fps but just a statistic. Useless in case of stuttering, flight feeling, fluidity and all of what I focus on here.

     

    6. VR asynchronous time warp/asynchronous reprojection help much in case of dropping to 45fps but will break flight feeleing and in case of infrequent drops it will be unpleasant stuttering of game objects (not your view).

     

    7. In VR if you drop to 45fps your head will still move with 90fps(see above) but ground and all objects inside game will move 45 fps (every second frame) - hence frame jumps and stuttering. Most of it when you fly fast and look sideways (not in front of you) at the ground.

     

    8. Even if you don't use Vsync or VR all of above affects your fps quality (BMS example above)

     

    9. After all tests I lowered my CPU speed from 4.7GHz to 4.0GHz to see what diffrence it will make. I've got about 0.5-1ms more on every test maximum in v1.5.8 tests.

     

    10. You should turn off any affinity bullshit from autoexec.cfg (if you edited that). It can ruin CPU frame time consistency (increase frame time variation). Leave it at default auto (all cores).

     

    11. While testing I changed process priority to HIGH for DCS.exe, vrcompositor.exe, vrserver.exe to decrease frame time variation. I don't recommend setting it to real time because it could impact input latencies or make game unstable (I crashed couple times). But all in all helps coz Windows 10 wants to do every unimportant action while I want to squeeze every ms from rig :doh:. I'm not utilizing CPU 100%, just want to be sure DCS will be first in line. If you use oculus remember that setting DCS.exe higher without oculus rendering pipeline processes can make DCS slower not faster.

     

    12. testing GPU and CPU frame times is the only proper way to tell why those frames you have don't give you expected flight quality. Only way to tell if you should have new hardware. Only way to know if this new CPU is worth the money or not.

     

    13. Someone asked me important question Why do I turn off terrain shadows and cockpit global illumination in prefered settings if it had no impact to performance?

    It has impact on performance - just not on CPU frame render times. First you need to take care of CPU if it makes in time with frame data than You want to max out your GPU potential but not overload it and make it in frame time. All in all i can't have 11ms in VR so I'm choosing lower than 22ms variant for both CPU and lower than 22ms for GPU.

     

    14. I wanted to know is if it's possible to use DCS without stuttering in 90Hz in VR with current existing hardware. If it's possible - I leave this question to you.

     

     

     

    *I measured the impact of the DCS graphics settings on CPU frame render times VERY roughly with Steam frame statistics tool while running DCS in VR. Every game graphics setting was tested with ALL others turned off or lowest possible. I've chosen two Su-25 missions which struggle to give good performance on my rig even on lowest settings. I tested simplest possible scenario standing on runway in VR in singleplayer. If this struggles with stable frame times and asynchronous time warp/asynchronous reprojection kicks in than more complicated air battle or multiplayer wont work with stable 90fps. Measurement was done in cockpit (simulation was of course started by clicking start mission). Intel speed step turned OFF and all of possible sys settings to high performance. My CPU is 4.7Ghz watercooled and it's always 4.7GHz without any boost/ jumps or anything. My Rig is in my footnote. With hardware I have i'm not GPU limited but CPU limited. I hope my work will be useful to you. I will update it with 2.5 stats.

     

     

     

    DCS 2.5.0.13818.311 - in VR

    NVIDIA 386.69

    Simple analysis:

    Differences between engines are very clear when we measure frame times instead of average fps. v2.5 engine is much better than v1.5 no doubt about it. I'm very impressed, great work DEV team! :thumbup::thumbup::thumbup::thumbup: Waiting for more to finally play in VR at 90fps instead 45fps (Vulcan renderer? Advanced rendering pipeline for VR like lens matched shading and simultaneous multi-projection?)

     

    CPU times on lowest settings are little higher than v1.5 but I see much less load on CPU overall and more load on GPU which is very good. v1.5 had too much load on CPU especially under VR. Render object counts decreased substantially (great - it was a big problem for v1.5 and quite a trouble maker - proof that v1.5 was not optimized properly some users didn't believe)

     

    DCS v2.5 Engine looks as single threaded.:huh: :huh: Apart from directinput threads, sound threads, starforce threads, it looks there's no threads for simulation, ai or anything. No change here from 1.5:huh: :huh:.

     

    Graphics texture size change don't need engine restart - nice touch and sign of new renderer. Same with tree and cluter/grass settings change in mission. Handy for testing ;)

     

    Water results show long awaited optimization in obvious "no water here" scenario so we can proudly say we can stop measuring water performance in the middle of plains. :doh:

     

    Top of the roof latencies from water/visible range and civ traffic has been steadied out finally. Visible range frame times has changed surprisedly. Maybe some map optimizations/changes helped here. We need better test scenario.

     

    Speedtree is great, much much faster than 1.5 - there's no comparison. Another example of v1.5 unused potential for optimizations.

     

    Pay attention to anisotropic filtering - it governs look of speedtree trees. Low settings here look awful.

     

    Without deferred shading there was ~0,5ms less frame time on lowest settings in both tests.

     

    Obiously we need much better testing scenario now i.e. for terrain shadows, trees, water etc.:thumbup:

     

    My prefered DCS graphics settings for VR are on the end of this post. Prefered DCS graphics settings CPU frame times (lower right corner of results print-screen) are measured not calculated.

     

    DCS 1.5.8.13716.422 - in VR

    NVIDIA 386.69

    Simple analysis:

    Where delta is 0ms there is no CPU bottleneck. It's GPU bound. So if you have good GPU just throw it at GPU but watch out for maxing GPU.

     

    GPU is hard to measure like this because it scales with load. So if you go low settings it puts its finger in its nose and render it in 11ms. If you throw more calculations at it it will scratch its head give some more power and..... you guessed it - render it in 11ms.

     

    First test on my rig on lowest settings i had 8ms CPU render time (3ms reserve from 11ms 90Hz frame time limit for CPU) I could set i.e. civ traffic to medium (+2ms) and water to medium (+1ms) to make frame in 11ms. BUT bear in mind that frame times are very unstable especially in DCS so you should leave ~2ms reserve.

     

    Second test on my rig on lowest settings i had 12ms CPU render time (1ms OVER 11ms 90Hz CPU frame time limit) - no fun with 90fps

     

    Uppon setting all those to maximum CPU frame times would gone far beyond 24ms... In this case GPU doesn't do much - just wait for CPU..

     

    Shadows are interesting. If your gpu can render shadows (most of you have 1080's/ 1080ti's so it can) CPU is the real bottleneck for them. But if you really want them - it does not matter if you choose Low or High - it's 4ms - no difference. Just go High if GPU is good enough.

     

    It's been 2 years from this analysis. They did not find a cause of stutter but they had the same conclusions about minor impact of todays GPUs for stuttering problems. Here you have the cause. Sadly after 2 years not much has changed.

     

     

    DCS 2.5.0.13818.311 - in VR

    NVIDIA 386.69

    RodE7ae.png

    DjOWf2R.png

     

     

     

    DCS 1.5.8.13716.422 - in VR

    NVIDIA 386.69

    lS4qGZd.png

    v8Uj1C4.png

     

     

    DCS preferred settings for VR

    Xk5kjuR.png

    • Like 11

    [MERGED] DirectX 11/12, OpenGL, VulkanAPI Discussion

    in PC Hardware and Related Software

    Posted · Edited by soundslikerust

    I only play at WQHD and not 4k but my poor single GPU is always 99-100%, so no, the bottleneck with an 8700k @ 5.2G is your single 1080Ti, which also runs 10-15% oc.

     

    I could use another 1080Ti, if it worked for DCS. Yes, si I have steady 144fps everywhere on every map, thats the goal.

     

     

    It for sure does for mining :) running my old 980gtx along my 1080ti for mining till i send it to RMA next week, the fans of the 980gtx failed. not an issue as I looped it up to the watercooling system.

     

    That's why your GPU is utilized 100% - Run a Vr with static time for every frame, get it to 4k and it will change to cpu bound. CPU can be utilized 30% and be a bottleneck at the same time just because game engine can't push frame fast enough. You forgot what is really important here - not your average fps but a frame time. With all stuttering and inconsistencies of DCS engine and DCS maps... No matter what you do there will always be places in DCS where frame times spike above 11ms wchich will crush your useless average 144fps. I have the same card as you - frame times and latency are the most important problem to solve. Vulkan can change everything in case of draw calls. Let's hope that it will get stable frame time in less than 10ms no matter where and when. It would be great.

     

    Latency is what people perceive as a sense of flying and speed. That's why BMS is regared as good at it - it's old as hell and have very low frame latencies. o7

    Huuuuge fps drop-spikes quite often!

    in Game Performance Bugs

    Posted

    Better Optimized DCS 2.0 = DirectX 11 vs DirectX 9, and an updated Terrain Engine, Unified UI, and about a dozen other listed objects.

     

    no where does it say, Re-Coded to resolve Draw Command Upper Limit CPU Overhead caused by DirectX API Kernel

     

    I'm pretty sure I know more about what ED is and isnt doing, on multiple levels.

     

     

    Seems your intent on engaging in a debate instead of accepting the truth about the root of the problem.

     

     

    As much as I'd like to debate on the code level DirectX handicaps for the last 24 years since Microsoft Debuted the DirectX Software API Layer to Render 3D Objects across every supported GPU Architecture from ATi (CiF), nVidia (NV1), SiS (S3D), 3DFx (Glide), Matrox (MSi), and about half a dozen generic Brands (Trident (3Di/Blade), etc etc etc.

     

    I have other things to tend to that are vastly more important.

     

    ouch not nice, your background is fine, you wont know mine anytime soon because its not facebook. Our expertise is not a main problem here. Thanks for your opinion

    Huuuuge fps drop-spikes quite often!

    in Game Performance Bugs

    Posted

    DirectX Commands have nothing to do with Graphics Memory, nor System Memory.

     

    DirectX Commands Have nothing to do with CPU utilization,

     

    The DirectX Command Kernel itself is Multi-threaded by default, however it will never peg a CPU at 100% because it has a Software Limit.

     

    Once the Commands per Cycle Reach the Limit, Everything Bottle necks, as the API was not designed to process more than that, it's not a Hardware Issue, it's not a DCS Issue, it's a DirectX Issue.

     

     

    PS. 15 yrs Experience Building Gaming Rigs is Impressive, Congrats, You came in after Intel already Shafted AMD, CyRix, IDT, and Rise CPU manufacturers.

     

    I was Building Computers Since the 286 Era, through 486, Through Pentiums, Through Athlons, Through to Today's Hardware, so, roughly 25+ years.

     

    my first was 386sx so you won. I'm an engeener. Everything you wrtote is fine almost. There's one thing more. When there are botlenecks in multithered ops, and no vital PC component is utilized more than 50%. What is the botleneck?

     

     

    algorithm/implementation ;)

     

×
×
  • Create New...