the workaround doesn’t seem to work for me either
“doesn’t work” takes many forms & your best bet is elaborate on it a little bit more.
as in the original issue still happens, i get an InvalidOperationException if I don’t copy the array
I’m facing this same bug in Unity 2019.4.21f: any plan to backport it to 2019 LTS?
I can read “Could not test with: 2018.4.30f1, 2019.4.17f1(Missing script references)”, so I’m unsure if 2019 is not on list because it’s too old or because nobody reported this bug for that version.
When fix for the STABLE unity version 2020.3 will expected to land?
Hey @richardkettlewell , is there any update on when this might be fixed? The status hasn’t changed since May. Thanks!
I nudged the team, I think there was a problem with the fix so it had got stuck… hopefully they are going to look at it again now and finalise the fix.
@richardkettlewell thanks mate
Thanks @richardkettlewell !
Do you know if there is any plan to fix it on the 2019.4 as well?
Several people reported it to happen on this version too
Thanks for highlighting this. We hadn’t planned to do a 2019.4 backport because the bug repro project wasn’t working at all in that version. But we are going to do the backport based on your feedback. the issue tracker should show that soon (it takes a couple of hours to refresh)
Also, the fix is looking good to land in our mainline version in the coming days, which is the first step towards getting it into the various releases.
That is EXCELLENT news, thank you!
Hi all, the fix has finally landed in 2022.1.0a12.
This means the backports will now be unblocked and can land in the main releases.
On the one hand it is a great news, on the other one year have passed since the original issue was reported. And knowing how quickly backports are done, it will took a half of the year to backport this changes to the STABLE 2020.3
Also I really could not unerstand why this bug took one year to fix.
Hey @richardkettlewell , the new changes seem to work but I’m getting some curious errors. At the start I allocate a persistent NativeArray and pass it into AsyncGPUReadback like this:
request = AsyncGPUReadback.RequestIntoNativeArray(ref data, computeBuffer);
I get the data back as expected and reuse the same NativeArray in later frames in subsequent calls to RequestIntoNativeArray. This all works as expected, but I get an error in the console on every call:
AsyncGPUReadback - NativeArray should not be undisposable
Finally, if I try to free my NativeArray, I get the following error at the very end:
InvalidOperationException: The Unity.Collections.NativeArray`1[System.Single] has been set to undisposable and cannot be deallocated.
Am I missing something here or is this a bug? Is RequestIntoNativeArray marking the NativeArray as undisposable by mistake in this situation? When I run the game again it logs yet another error that a NativeArray wasn’t properly disposed (assumedly because it was marked as undisposable by RequestIntoNativeArray).
Thanks!
Also, is there any news about this? The issue tracker is still not mentioning 2019.4 at all
Sorry I’m not involved with the fix in any way, your best option would be to report a new bug
The dev handling the bug decided not to backport to 2019.4, I’m not sure of the details eg why not
@richardkettlewell , I’ve logged a bug per your request entitled “RequestIntoNativeArray marking array as undisposable.”. It said not to share the FogBugz url though.
Using 2021.2.6 seems to fix RequestIntoNativeArray in “one way”.
The way I want to use it doesn’t seem to work, I am unsure if it should be allowed.
Instead of calling it once and waiting for the result I want to call it multiple times per frame (while modifying the buffer with compute shaders in between), and then process the results as they arrive.
But now, after calling RequestIntoNativeArray the first time, the native array has the current state:
System.InvalidOperationException: The Unity.Collections.NativeArray`1[System.Int32] can no longer be accessed, since its owner has been invalidated. You can simply Dispose() the container and create a new one.
And this state is reset once the readback is complete, so I cant call RequestIntoNativeArray again immediately.
So is it correct that you relinquish control over the array until the data request is complete?
This is related to a question I asked recently ( Where is data buffered when getting and setting data to a compute buffer/shader )
You can share the case number though, if you want to. Just not the entire URL, as that is personal just for you.