Search Unity

  1. The 2022.1 beta is now available for testing. To find out what's new, have a look at our 2022.1 beta blog post.
    Dismiss Notice

Gfx.WaitForPresentOnGfxThread

Discussion in 'Editor & General Support' started by N1warhead, Aug 20, 2019.

  1. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    What is this and why have I never seen this until recently? And most importantly why is it killing performance when it didn't do it before in older versions? It seems like the more things they expose into the profiler the slower things get.

    Heck I even went out and bought GPU Instancer - and things got multitudes of times slower because of whatever this is when GPU Instancer should make things considerably faster.

    In fact GPU Instancer makes it take 250+ MS per frame at times, but averages 50-60 MS per frame.

    Turn off GPU Instancer - with 50,000 trees on a terrain I get roughly 23ish FPS, with GPU Instancer - 1.5-10FPS...

    I'm emphasizing GPU Instancer in this case because it's supposed to optimize things. But it's not only GPU Instancer, even Voxeland bring up this dirty problem.

    So how can I get rid of this, if it's even possible. I've tried the last 3 versions of Unity and this problem is persistent and it's breaking performance to the point it's impossible to make my game.

    [Edit]
    I feel I should mention: I just turned off GPU Instancer and left the scene like a regular scene and this problem goes away... So yeah, Voxeland and GPU Instancer both have this problem.
     
    Last edited: Aug 20, 2019
    deus0 likes this.
  2. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,165
    This happens when the stuff the CPU needs to do is finished before the stuff the GPU needs to do. So it waits until the GPU is done.

    Adding more stuff to the gpu would naturally make the gpu take longer each frame and therefore would make the wait time longer.

    But you're also saying that everything is slow and such, like your fps is worse, which should be another problem entirely. Have you profiled the GPU?
     
    deus0 likes this.
  3. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    But the problem is - it's coming from tried and true assets on the asset store that seems to be nobody else is complaining about this problem but me. But it only happens when I use said assets.

    Scene without GPU Instancer - thousands of draw calls is better than a scene with 80 draw calls with GPU Instancer.

    I can't do GPU profiler, apparently isn't supported for AMD Rx 480.

    Don't don't confuse this with Gfx.WaitForPresent, (Unless this is that renamed to : WaitForPresentGfxThread.)

    Another example would be Voxeland. I'm not sure if You've used this or not, but I tested this theory out. I started a fresh new project and imported only Voxeland, changed nothing but to Linear color space (like I always do). And bam the moment the player gets near the grass meshes that come in the demo scene - instantly 15 FPS. The main culprit? Gfx.WaitForPresentGfxThread... Didn't change anything, didn't do anything but change to linear color space, gamma didn't make a difference either.

    If I remove GPU Instancer: the whole Gfx.WaitForPresentGfxThread disappears. And same with Voxeland.

    Map Magic on the other hand - it doesn't exist on, so that works fine.
     
  4. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,165
    To debug gpu, you have to disable graphics jobs in the settings, I believe
     
    deus0 likes this.
  5. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    Alrighty, I'll try that and see if that works.
     
  6. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    Turns out Graphics Jobs was already disabled lol.
     
  7. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    upload_2019-8-20_15-59-40.png

    But this still doesn't make sense to me because you'd figure GPU Instancing, and even a basic baren Voxeland demo scene would be far superior than rendering everything outright without any form of Instancing and culling.

    Like literally - Remove GPU Instancer and put a lot more work on the GPU = better performance. Like that makes any sense. It doesn't.

    I mean if someone can explain to me how 10 million polygons, 1000+ batches, 800+ shadows is better than 119.4K Tris, 60 shadows and 154 batches I'm all ears. (because this is what GPU instancer is giving me).

    Also again - on Voxeland the same exact problem - I could literally have 1 single piece of grass and the moment the player gets within a couple meters - this Gfx.WaitForPresentGfxThread appears and kills all performance. Literally a single piece of grass.

    [Edit]
    Yes I've tried starting a new scene with only a regular terrain and one thing of trees, same issue - Gfx.WaitForPresentGfxThread kills all performance ONLY if GPU Instancer is in the scene, otherwise I get better performance just handling all the data at once.
     
    deus0 likes this.
  8. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,165
    Putting more stuff onto GPU doesn't necessarily mean better performance. Remember that if the GPU is getting 30 fps, then so will the CPU, since it has to wait. The more stuff you make the GPU do, the slower it is. This is called being GPU-Bound. And, as you can see by the profiling, the GPU is having a very hard time for some reason, with a very low fps. So this is the reason why WaitForPresentGfxThread is happening.

    So now lets see why the GPU is having such a bad time! First off, what graphics card are you using? Also, could you show what the profiling looks like with GPU Instancer turned off vs on?
     
    khanism and deus0 like this.
  9. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    I'm on an AMD Rx480.

    Without GPU Instancer - this is how it looks. Practically non-existent except at the start (On the left side of it).
    upload_2019-8-20_17-17-37.png
     
  10. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    The first image is with GPU Instancer on (a couple messages up)
     
  11. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    oh and here's a profiler image with a selected sample area.
    upload_2019-8-20_17-23-0.png
     
  12. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    And this is for Voxeland. Keep notice of how the GPU skyrockets after a period of time.
    The issue with this is - the grass can be visible from a distance and stay fine. But the moment a player gets meer meters from it - the chaos instills with this same problem. But yet - nobody on this green earth experiences none of this but me. Literally straight off the demo scene, not a single thing changed. But yet - none of the other countless hundreds or even thousands of people have complained about this. (The Spikes in the CPU) are from the Gfx.WaitForPresentGfxThread.

    upload_2019-8-20_17-33-13.png


    [This is the same image as above, but with the grass rendered at a distance] - the above only happens when walking near it, and only when near it.
    upload_2019-8-20_17-38-25.png



    [edit] I think I should mention that I have used Voxeland in the past - with no issue. So I'm really starting to think Unity has a bug somewhere that simply don't like my current graphics card. I've never downgraded a card, so if anything my current card is better than my last if I tried it last time on my old card (it's been awhile, so I can't say) if it was this or the last card. My last card was an R9 290. (not 290x)
     
  13. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,165
    Once again, this is clearly something on the GPU side, not by WaitForPresentGfxThread directly. WaitForPresentGfxThread is caused by having a lot of computations on the GPU, and as you can see, this is clearly happening. But yeah, I have no clue what is causing this massive explosion of GPU calculations. Looks like BatchRenderer is a lot of the time, specifically the BatchRenderer.RenderSingle / BatchRenderer.Flush calls.

    Lets look deeper. If you extend the BatchRenderer.RenderSingle, we'll see what sub functions are taking most of the time. : )

    EDIT: I'm talking about the voxelland one, by the way. Looks like Voxelland and GPU Instancer are causing entirely different issues, from the look of it. For now, the Voxelland one looks the most interesting, so lets focus on that one for now.
     
  14. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    Yeah I hear you mate, I do appreciate the help though.

    (This is where it runs fine).

    upload_2019-8-20_17-50-5.png

    Now this is where it becomes horrid.
    upload_2019-8-20_17-50-58.png
     
  15. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
  16. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,165
    Very interesting, looks like batching a single mesh is taking 103 ms to render. Wowee.

    Now figuring out why this is will be interesting. If you click the details button on the right of the hierarchy window, it should have some info related to the name of the mesh and such. You could also try looking at the frame debugger to try to find which step is that rendering step, which should have some more info
     
  17. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    Well I just had a buddy with a GTX 1070 try it and he said it was butter smooth. I mean sure it's faster, but mobile phones can play games made with Voxeland...

    So it's making me think that this is an AMD related issue.

    Well Details window it shows
    upload_2019-8-20_18-27-11.png


    And this is the frame debugger.
    upload_2019-8-20_18-30-57.png


    But I feel I should emphasize - this only happens when the player gets close to a grass piece. You could be 100 meters away and look at all the grass and keep perfect FPS, but the moment you get close, that's when the issues happen.


    Hence why I'm thinking there's a bug in Unity and AMD cards. Because Voxeland has been used in mobile android projects in the past and simply worked. Not saying without any overhead, but if a phone can have grass, certainly my card can have grass lol.


    [Edit]
    The literal only thing I can think of aside from the above is if something has changed in Unity API that is causing so many issues with both GPU Instancer and Voxeland to where it isn't updated for current Unity versions. But still, GTX 1070 ran it butter smooth. Mobile phones have ran Voxeland in the past as well. So i'm not entirely sure, I just know I'm getting so exhausted trying to figure this out.
     
    Last edited: Aug 20, 2019
    deus0 likes this.
  18. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,165
    Is the frame you're showing the one that is causing the issue? If so, maybe that would explain why distance is a factor - shadows are only rendered for nearby stuff. If you disable shadows does this lag spike still happen?
     
  19. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    Just tried, still happens, - just as bad.

    It's not a spike by the way, it's constant bogging. The best way to describe it would be to run 10 debug logs in update at one time in 10 different scripts.. That constantly - lag the frames never giving them a chance to reach higher counts.

    Well I'm going to head to sleep now, I appreciate the help. I'll probably contact Unity support tomorrow when I wake up, or file a bug report, or both. Because something simply ain't right with all this going on.

    I might simply reformat my computer, perhaps I got old conflicting drivers fighting eachother or something, considering the built in Video recorder for my graphics card can't even pick up my microphone input, makes me wonder what else may be going on with my computer.

    But before anything I'll probably stick my brothers 1060 in my PC, which is pretty much equivalent to my RX480, just a slight bit better, so should be more on par with what I have vs a 1070. Even though, like I've said - mobile phones from 3 years ago have had Voxeland stuff on their games before, so something is a big culprit here and something tells me it's simply something wrong on Unity's end, or AMD's end.
     
    joshcamas likes this.
  20. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    Well a clean windows install and AMD graphics drivers didn't fix the issue unfortunately.
     
    deus0 likes this.
  21. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,165
    Hmm... I'm afraid I'm not sure how to help you further, sadly :( Maybe someone from Unity can give some insight?
     
  22. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    It's okay mate, I really appreciate all you've tried to help with though :).

    I'm trying to file a bug report now and leading them to this thread.
     
    joshcamas likes this.
  23. Lynxed

    Lynxed

    Joined:
    Dec 9, 2012
    Posts:
    113
    I'm having wired spikes in 2019.3.b04 build.

    upload_2019-10-3_2-35-34.png

    I'm using a lot of GPU-instancing. I did not have problems with this on 2019.3.a11
     
    deus0 likes this.
  24. Xavier78

    Xavier78

    Joined:
    Oct 13, 2013
    Posts:
    34
    This issue exists in many unity versions for me. I use to solve it by adding -force-opengl in a .bat @N1warhead can you try using that flag in a bat file to start your unity to see if this solves the issue. @Lynxed this isn't working for me on 2019.3b since the unity.exe actually is starting unity hub, so I think the flag is getting lost somewhere so this probably won't work for you.
     
  25. GoldFireStudios

    GoldFireStudios

    Joined:
    Nov 21, 2018
    Posts:
    103
    @N1warhead Did you ever end up finding a solution for this? I'm running into the same thing using Vegetation Studio Pro, which is also doig GPU instancing. I'm running on 2019.3.10 and have an AMD Radeon Pro 5500M.
     
  26. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    I apologize for a long delay in response, been busy working on my game.
    Unfortunately I didn't, best of luck trying to find something that may work for you.
     
    deus0 likes this.
  27. deus0

    deus0

    Joined:
    May 12, 2015
    Posts:
    203
    From testing, I was rendering unique voxel meshes. I realized after reading this thread GPU instancing probably spends time trying to group up all those meshes or something, so there was overhead for GPU instancing. So I turned it off on materials with unique meshes and I stopped getting the mentioned GPU stalling bug. I believe it was the CPU compiling all the meshes or something into a 'instanced' draw call.
    Not sure, pretty sure I explained that terribly, but turning off GPU instancing on materials where I have unique meshes seems to of fixed it for me.
     
  28. radiantboy

    radiantboy

    Joined:
    Nov 21, 2012
    Posts:
    1,397
    Just started experiencing this now. Camera.Render is using 22% and WaitForPresentOnGfxThread using 64%. Anyone figure this out? I dont think im using instancing or anything special, never seen this before but it kills fps.
     
  29. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,165
    This means you are GPU bound. Have you used the GPU profiler?
    https://docs.unity3d.com/Manual/OptimizingGraphicsPerformance.html
     
  30. radiantboy

    radiantboy

    Joined:
    Nov 21, 2012
    Posts:
    1,397
    Not even seen that will try it. Though I cannot be gpu bound I'd say, used to work fast as hell until recently. It's almost as if occlusion culling is off because it's when I look back at a big city. But OC is on, could be mixed lights causing the GPU bound, I just changed them from baked because they weren't working. Thanks
     
  31. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,637
    That's exactly what happened. It's the same thing just renamed. Generally speaking, if a profiler sample is named "WaitFor*" you are looking at the wrong thread and should very likely not be using Hierarchy view but instead look at the CPU Timeline to make sense of what's going on. The rename was intended to highlight that fact a bit more explicitly and to redirect attention to the Render Thread. The manual page on Common Profiler markers has explanations for all of these.

    So with that in mind, check out Timeline view. See how the frames progress in a chronological fashion from present to present.

    If your Render Thread takes longer to prepare and issue the draw calls, than the GPU takes to process this all (Gfx.Present), try shuffling more work onto the GPU, e.g. via GPU instancing. If the opposite is the case, do the opposite. GPU batching isn't a magic bullet for "make things go fast". If the GPU is overburdened and the CPU idle, you did yourself a disservice with it. Use the Frame Debugger, GPU profiler and likely if that doesn't work or provide enough info, RenderDoc and your GPU or Platform manufacturer's Profilers. AMD, NVidia, ARM, they all have them and can provide further details.

    If you are batching/instancing things, make sure that you aren't hindering your Occlusion Culling with that (all batched/ instances objects are drawn even if some would normally be hidden) and that it's not trying to batch/instance unique objects.
     
    Last edited: Jan 29, 2021
    IMC-Lab and joshcamas like this.
  32. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,165
    Could this be added to the Unity Docs? This is great info!
     
  33. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,637
  34. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,165
    Oh, I've never seen this xD Whoops
     
  35. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    1,637
    Well, that particular page is only about 1 month old but the content was previously part of the CPU Profiler Module page for somewhere over a year ...
     
    joshcamas likes this.
  36. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,165
    Ah that may be it, I remember being stuck in this several years ago. Shouldn't have assumed things haven't changed. Great to see that profiler doc, looks awesome!
     
    MartinTilo likes this.
  37. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,875
    I appreciate your messages mate.

    But something else is wrong to be totally honest.
    For example, the past few days I've been trying to use the legacy built-in pipeline as I wanted to be able to use compatible assets for a project, but I can't, so I am forced to go back to HDRP.

    In legacy built-in - literally 2 trees at 5K Polygons each drops my FPS to 12. In HDRP - literally tens of thousands of trees (at LOD 0) (20K Polys each) (obviously better shaders in HDRP) and I'm having 80+ FPS using/not using GPU Instancer on the literally same exact stuff.

    I've determined where the issue was at after all this time - Overdraw. The moment I make these trees in built-in pipeline Opaque - the issue suddenly disappears. So I was like hmm okay let me adjust the cutoff value on the Legacy Speedtree shaders and made that value 0.01 and it helped a bit, but still not great. Instead of 12FPS I was getting more like 35FPS. (For a couple of trees).

    In HDRP however this issue completely is removed. I no longer have any single issue at all anymore.

    Now, if HDRP works fine why would I ever want to go back to Built-In? Because It's quite frustrating waiting for grass to become available for the terrain in HDRP. A terrain without grass is kind of boring lol. But a world that bogs to oblivion in Legacy Built-In is equally just as bad.

    For awhile I've honestly thought it's simply just my PC. But I've been playing even AAA open world games on ultra settings and never ran into these form of issues. So it's literally almost made me want to give up game dev after 20+ years in this field when I can't even handle two trees and thinking it's been my fault this entire time, in reality the problem lies in legacy built-in pipeline and no matter what anyone says it's simply a fact. Perhaps you may or may not can witness the issue doesn't mean it doesn't exist.

    I can see if I was using Hero tree assets at like 100K Polygons, thousands of branches and individual leaves,etc) and wind animations, etc. But when A 5K Poly tree that's simply a Tree Trunk and a few quads for the branches and leaves destroys performance in built-in pipeline then that's a problem that doesn't lye with me, and it's finally about time I accept it really isn't my problem and being straight up depressed and upset at my self for it. The problem lies within the legacy pipeline, and unless your team followed my steps very specifically they aren't going to find the problem, I've tried to put it as accurately as possible, even an RX 580 handles it perfectly fine and it's not even much better than my card.

    I mean I'm a reasonable person, but you don't know how many sleepless nights i've had trying to solve this problem and really how depressing it is to start a project and next thing you know you're 20 more projects ahead because you have to keep giving up on the other ones because of this issue that just doesn't seem to be getting fixed,and it is a problem, a problem with Unity legacy built-in specifically, not a GFX Card or CPU problem, it is straight up a Unity problem that needs to be fixed.

    I'm sorry if this sounds like a rant, it kind of is and kind of isn't. It's just really frustrating because I want to use built-in pipeline for the asset support, and the lack of grass in HDRP.

    But it's really not a hardware problem, it's specifically a legacy built-in pipeline problem.

    EDIT: In fact the two tree's im speaking about specifically that are 5Kish polygons are your Book of The Dead demo. It's one of the slanted pinetrees. It's a simple trunk with quad branches/leaves.

    Edit 2: Please forgive me, I was just rather emotional at the time of writing this as it sort'of hits deep at me personally because I wasn't exaggerating the amount of projects I've abandoned because of this issue. I'm just going to stick with HDRP I suppose and try to figure out a grass solution myself.
     
    Last edited: Feb 22, 2021
  38. cloverme

    cloverme

    Joined:
    Apr 6, 2018
    Posts:
    120
    Not sure if this will help anyone... I was getting Gfx.WaitForPresenfOnGfxThread slowing everything down, consuming +40% in the profiler dropping my game from 120fps to 20fps. It would only happen when the game was running in fullscreen in an HDRP project. Turns out for me, the culprit was running Depth Of Field in a Volume where Quality was set to "High", changing it to medium made it go away. Hopefully this helps someone in the future as I found this thread while doing a google search.
     
    IMC-Lab likes this.
  39. Pat27

    Pat27

    Joined:
    Apr 29, 2013
    Posts:
    1
    In may situation the problem was GUI text, to big in size.
     
    IMC-Lab likes this.
  40. Zoryth

    Zoryth

    Joined:
    Dec 5, 2016
    Posts:
    99
    I went with the "gpu instance everything", some people even say that :p

    I will have to reconsider that.
     
  41. RazorPudding

    RazorPudding

    Joined:
    Sep 1, 2017
    Posts:
    8
    I'm having a similar issue. URP project, default scene, no changes.
    When I have my focus on Unity editor and the game is running at about 50 fps with about 20 ms in CPU and 2 ms in GPU. Then I click on any other window in my second monitor and it jsups to 250~ FPS with around 3.5 ms on CPU and still 2 ms on GPU.
    You can see in the image the difference between the two states
    Halp please!
     

    Attached Files:

  42. RazorPudding

    RazorPudding

    Joined:
    Sep 1, 2017
    Posts:
    8
    Figured out my problem, it was becasue I ahd gsync on. For some reason that is no good with the editor
     
    deus0 and N1warhead like this.
  43. Szmury

    Szmury

    Joined:
    Jul 19, 2017
    Posts:
    2
    Hey guys I was solving this problem and I did record my whole walkthrough through the problem in my case it was
    Nvidia Control Panel
    Solution in video

    Hope that someone is having the same problem as I do
     
  44. Rodolfo-Rubens

    Rodolfo-Rubens

    Joined:
    Nov 17, 2012
    Posts:
    1,170
    I'm also having this...
    What do you guys see on the GPU Usage module? (It is deactivated by default)

    In my case, it seems like most of the spikes comes from these:
    I'm also having this - did you guys looked at the GPU Usage module? It is deactivated by default. In my case, it seems like most of the spikes comes from these:
    2021-11-24 15_27_52-pm-64 - 2_Overworld - Windows, Mac, Linux - Unity 2022.1.0a15.2209 _DX11_.png
    Even on simple scenes...

    None of the steps above solved my problem, the only thing that did fixed was... disabling the shadows completely... ? I don't know why, my GPU is kinda old but I think it should be able to render shadows... (btw, this happens even with low res shadows)
     
    Last edited: Nov 24, 2021
  45. Rodolfo-Rubens

    Rodolfo-Rubens

    Joined:
    Nov 17, 2012
    Posts:
    1,170
    Just an update:
    I think there is an oversight on the engine's behalf somewhere. From time to time I see these spikes:
    I'm using everything builtin, no special shaders, vfx, anything:
    2021-11-24 15_44_50-pm-64 - 2_Overworld - Windows, Mac, Linux - Unity 2022.1.0a15.2209 _DX11_.png

    Here is a regular frame hierarchy screenshot, right before the spikes you see above:
    2021-11-24 15_44_25-pm-64 - 2_Overworld - Windows, Mac, Linux - Unity 2022.1.0a15.2209 _DX11_.png

    Someone else is having this?

    From time to time the 'Drawing' process decides to take ~20ms for some reason?
     
  46. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,165
    This looks like you're running it in editor, which can have questionable results. Does it have spikes when in a build?
     
  47. Rodolfo-Rubens

    Rodolfo-Rubens

    Joined:
    Nov 17, 2012
    Posts:
    1,170
    It's in editor, yes. I should make some test runs on a build for sure. But still, it gets extremely tedious to test stuff when it starts to stutter (as you can see on the graph, it's not a hiccup, it does this for a couple of frames, sometimes seconds, then stops, and it happens very regularly).
     
  48. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,165
    That is odd, I've never seen that personally. In your screenshot you're not showing what is causing the spike, however. You need to click where the spike is on the GPU section to see the hierarchy. Same for CPU.
     
  49. Rodolfo-Rubens

    Rodolfo-Rubens

    Joined:
    Nov 17, 2012
    Posts:
    1,170
    Hey, the spike is selected on the first image, I'm on the GPU usage module because that's where the cuplrit is (on the CPU Usage module we only have the GFX.WaitForPresentOnGFXThread)... that means the CPU is waiting the GPU do its thing right? And btw, the bigger spikes on the first and second images are just the EditorLoop, these get bigger in those stutter sections.
     
  50. Rodolfo-Rubens

    Rodolfo-Rubens

    Joined:
    Nov 17, 2012
    Posts:
    1,170
    Sorry guys! After a long time not playing any games on my laptop I decided to play something and I noticed that a lot of games is having this same stuttery sections throughout the gameplay, even on older games, so that's not on Unity.
    No idea why this is but since this is an old laptop (it's a Dell G7 from mid 2018's), I tried a lot of settings on NVIDIA Control Panel, NVIDIA Experience but that didn't change anything, also cleaned the fans and that seems to have improved a bit. Anyways, I'll let this thread now. Thanks!
     
unityunity