Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.

Question Change m_AllocatorLabel after NativeArray is initialized

Discussion in 'Entity Component System' started by RendergonPolygons, Jan 26, 2022.

  1. RendergonPolygons

    RendergonPolygons

    Joined:
    Oct 9, 2019
    Posts:
    97
    Hello

    I am using this Unity Jobs example to explain the behaviour:

    When initiating a native array of Color32 so that I can set the Allocator, the texture colors do not update:
    Code (CSharp):
    1. var data = new NativeArray<Color32>(m_Texture.GetPixelData<Color32>(0), Allocator.Persistent);
    m_AllocatorLabel is set:
    upload_2022-1-26_8-30-38.png

    Texture Colors do not update:
    upload_2022-1-26_8-30-56.png

    However when the nativearray is initialized like this, the texture updates correctly:
    Code (CSharp):
    1. var data = m_Texture.GetPixelData<Color32>(0);
    NativeArray Allocator is None because I could not set it when initialized this way:
    upload_2022-1-26_8-31-30.png

    Texture colors update correctly:
    upload_2022-1-26_8-32-18.png

    Can someone shed some light please:
    - is this behaviour a bug?
    - if I initialize the nativearray so that texture colors do work correctly (var data = m_Texture.GetPixelData<Color32>(0);) how can I set the Allocator after initialized? I don't see this in the documentation.
    - Does Allocator.None behave like Persistent? If I don't dispose off the native array when initialized without setting the Allocator, I can't see an error on the editor logs saying a nativearray was not disposed.

    I'm using Burst, sorry if this is not the right place to post as I'm not using entities but i'm using mono and jobs. I'm on Unity 2020.3.22, Burst 1.4.1, Collection 0.15.0 prev .21, Entities 0.17.0-prev.42, Jobs 0.8.0prev.23
     
  2. julian-moschuering

    julian-moschuering

    Joined:
    Apr 15, 2014
    Posts:
    502
    It's not a bug.

    In the first case you create a copy of the texture data. Modifying it has no effect on the actual texture.
    In the second case you use the actual texture memory. It's memory is managed by Unity and there is no need to dispose it.

    From the documentation:
     
    RendergonPolygons and Baggers_ like this.
  3. RendergonPolygons

    RendergonPolygons

    Joined:
    Oct 9, 2019
    Posts:
    97
    Thank you @julian-moschuering , that explains !

    I have another follow up question , maybe I can save opening a new thread please - I am looking to keep the managedarray alive for the life of the game: are there any obvious performance considerations for a NativeArray managed by Unity (disposed by GC I am guessing) and that I use for jobs than a NativeArray I create for a job which I am responsible for disposing off?
     
  4. julian-moschuering

    julian-moschuering

    Joined:
    Apr 15, 2014
    Posts:
    502
    I don't think there are performance issues but it might not be save to do so as there might be events the memory is reallocated. To be safe you should stick to the documentation and not do that:
    Eg refetch the NativeArray each frame and pass it to your job and drop it when calling Apply
    or
    create your own persisent NativeArray and write it to the texture using SetPixelData. Depending on the Graphics API in use the latter might have a small overhead due to doing an additional copy.
     
    RendergonPolygons likes this.