Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Resolved How can I find the cause of a delay before Camera.Render on m1 mac?

Discussion in 'General Graphics' started by Baggers_, Nov 23, 2022.

  1. Baggers_

    Baggers_

    Joined:
    Sep 10, 2017
    Posts:
    98
    Hi, I'm a touch confused about some timings I'm seeing in the render thread on an m1 iMac. I am using Unity 2021.2.14f

    I would like to know what could be causing `Camera.Render` to start so much later on the mac than on windows. I understand there are naturally significant differences in graphics API and architecture, but I'm not sure how to go about finding the cause of the delay, regardless of platform.



    I've not included it in the image, but all jobs are completed on the mac far before `Camera.Render` runs, so it's not waiting on those (as far as I can tell).

    If there was more than a gap I would know where to start googling.

    I've also used XCode to debug the frame on metal and it doesn't show any significant timings before the call to `Camera.Render`, but there are some buffers created that it doesn't seem to give timings for.

    Any help getting started with this would be massively appreciated.

    Thanks folks.
     
  2. joshuacwilde

    joshuacwilde

    Joined:
    Feb 4, 2018
    Posts:
    725
    make sure to profile the editor, not the player, if you are running this in the editor. You won't get the full picture otherwise.
     
  3. Baggers_

    Baggers_

    Joined:
    Sep 10, 2017
    Posts:
    98
    @joshuacwilde thanks, but I'm not running the game in the editor
     
  4. Baggers_

    Baggers_

    Joined:
    Sep 10, 2017
    Posts:
    98
    Well that was lucky, it turned out to be a buffer upload that was taking a long time. I wish instruments made that a little clearer, but it makes sense.
    Cheers

    [EDIT]
    As I don't want future folks to find this unhelpful end to the thread. The specific issue was that I was updating ComputeBuffers which had not had their ComputeBufferMode set correctly. The default is ComputeBufferMode.Immutable, and with that mode, using SetData seem to have been recreating the buffer behind the scenes.

    By changing them to ComputeBufferMode.SubUpdates I was able to see the perf difference, but naturally this is not neccesarily safe, so ComputeBufferMode.Dynamic might make more sense.

    This was however the lead I needed to start tracking this down.

    Also, the "Insights" section of Metal frames capture in XCode can help point you towards things that might be slowing you down. It can be a bit overwhelming at first though.
     
    Last edited: Nov 24, 2022