Was trying to optimize getting data off the gpu just in case but while using ComputeBuffer.GetData completes without really hitching anything, for some reason using AsyncGPUReadback does the opposite of what it’s supposed to and freezes the game entirely.
Here’s the profiler on one of the hitches.
And here’s the code I’m using
Not sure what to make of this.
I’m running the latest 2019LTS version, not sure if this is something that’d be fixed in later versions but don’t really have that option anyway.
At this point I’d just want someone to sanity check me and tell me if it’s just broken or what.
I have the same problem, I tried to optimize some work by putting it async but getting data back with readbacks ends up being very slow with this problem
Same issue. Very frustrating.
This is, in my experience, most often caused by particle systems. Had MANY of these in 2019, in various versions of it.
I’ll ping @richardkettlewell as I think he knows more about this than anyone.
I’ve no idea, other than yeah it looks like a bug. It doesn’t look very async 
If you’re able to submit a bug report, the team that owns this can take a look.
Having the exact same issue, this makes no sense, why is the main thread blocking on an ‘async’ call?
I feel like the entire async readback API is unsuable in production, the slowdowns, errors, random crashes and workarounds required to actually do anything useful are ridiculous. Did Unity actually test this API and/or have any kind of demo use case where they are actually using it in a way that makes sense for performance?
Reading back GPU data is pretty common in a lot of algorithms such as virtual texturing and occlusion culling, it’s insane how convoluted and unusable it is in Unity.
I’m using Unity 6.2.6f2, and have switched my virtual texture system to using async readbacks into native arrays. After having to work around many other issues I finally got it working, but there’s a huge 10ms stall and another LargeAllocation.Free call, which I have no idea why it’s happening. My guess is that Unity is still allocating/doing some kind of copy on the unmanaged side, which defeats the whole point of using native arrays, and the Gfx.EndAsyncJobFrame stall defeats the point of making an async request entirely.
It should be very simple, you make a request, get a handle you can check until its done, and then your data is in the array you provided.
(Also on that note, why does commandBufer.RequestAsyncReadback not return a handle? All you get is a callback which is bad since for any high performance system you don’t want big chunks of work just happening at random points in your frame)
