Search Issue Tracker
Not Reproducible
Votes
0
Found in
2020.2.0a7
Issue ID
1238437
Regression
No
[GPU PLM] Editor stalls after closing error during GI baking when AO export is ON
Steps to repro:
1. Open the attached project and 'AVP6_Desktop' scene;
2. In the Hierarchy select 'Camera' gameobject;
3. In the Inspector scroll down to 'Test' component and press 'Turn On' button;
4. Make sure that the Progressive GPU Lightmapper is set in the Lighting window, if not, set it manually;
5. In the Lighting window press 'Generate Lighting' button;
6. Wait for 2-5 minutes and then close the Editor.
Expected result:
Editor is closed successfully.
Actual result:
Editor is stalled and cannot be closed. See the attached video and Editor.log file.
Regression introduced in Version 2020.1.0.
Notes:
- Reproducible in 2020.2.0a7, 2020.1.0b6;
- Not reproducible in 2019.3.10f1;
- The issue is potentially introduced by the changes to GPU Lightmapper's progressive updates;
- Reproducible only when baking with GPU Lightmapper, Optix denoiser and the AO texture export are enabled together;
- Reproducible when baking on GeForce RTX2080 in Windows.
The issue is not reproducible in 100% of cases and could be timing related. If it doesn' reprot try following:
- Wait for more time after starting the bake (5-7 minutes);
- Defocus and re-focus on the Editor window while baking prior to closing it;
- The issue might be related to the neverending bake issue (case 1199574). So, potentially to repro this bug you'll need to wait until the baking goes into the neverending loop and then close the Editor.
---------------------------------
Potential reason for the stall:
Render jobs for all the output types apart from lightmaps (so light probes, additional baked probes and custom bake) can be scheduled as soon as the previous job integrates. In the GPU lightmapper that however does not mean that the work is done, but simply that it has been scheduled on the OpenCL queue. That means that the scheduling logic can easily end up scheduling a lot of jobs quickly (as it takes very little time on CPU-side to do so), that will then take a lot of time to execute (as the work done on the GPU might be heavy).
The work is actually done when the readback confirms so. The just mentioned scheduling issues means however that the readback queue can get packed with many readback requests. When attempting to close the Editor we wait for all the requests to be done and that might take a considerable amount of time.
There are two parts to the fix:
1. Check for FinishedAllProbeSamples() in Execute() and return true if all samples are done. Types that don't do view prioritisation know precisely when they're done without the need to iterate over data.
2. Allow only a certain amount of render jobs in flight (from when a job is scheduled to when async readbacks started by a given job are done). Copy the approach used for lightmaps and use it for all the remaining types.
Additional note from Uygar:
Also, the order of the two function calls in void OpenCLRenderBuffers::ReleaseBuffers() seems odd, waiting on the readbacks before releasing the buffers seems more correct to me.
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- [UaaL] Freeze on "GetLightingSettingsOrDefaultsFallback()" when rotating device screen after unloading Unity framework
- A white vertical artifact is present when any Material from HDRI is used for a panoramic skybox
- Editor freezes when handling Havok collision interactions between a thin collider and the player controller
- No blue outline is shown on a folder in the Project tab when an external file is being dragged over the folder
- Profiler - Taking you to the wrong section when using 'show'
Add comment