We have been running into crashes around FFTBloom and LocalExpsoureApply. I turned on the d3d12 debug layer and found this line.
Line 9999: LogD3D12RHI: Error: [D3DDebug] ID3D12CommandQueue::ExecuteCommandLists: Simultaneous-access or Buffer Resource (0x0000020DB087C6A0:‘EyeAdaptationBuffer’) is still referenced by read|write|transition_barrier GPU operations in-flight on another Command Queue (0x0000020BB5B7E330:‘3D Queue (GPU 0)’). It is not safe to start transition_barrier GPU operations now on this Command Queue (0x0000020BB5DA1D90:‘Compute Queue (GPU 0)’). This can result in race conditions and application instability.
Setting r.LocalExposure=0 causes the validation error to disappear. It looks like the EyeAdaptationBuffer is being accessed by the compute queue, but some type of synchronization is required here. Not sure if that is a pass dependency between EnqueueCopy and ApplyLocalExposure or a transition barrier to go across queues.
I noticed several code changes to the eye adaption buffer logic and only updating when necessary. Still debugging on my side, but any help is appreciated. We are going to set r.LocalExposure=0 and see if this crash is reduced. Might not be related, but seems like something that should be cleaned up regardless.
[Image Removed]
Steps to Reproduce
This seems to occur in a scenes where r.LocalExposure=1 (the default behavior) and post process settings are taking the AddApplyLocalExposurePass code path combined with the AddHistogramEyeAdaptationPass enqueing readback/copies.
One solution to this problem. Explicitly put the ApplyLocalExposurePass on Compute so it also executes on the graphics queue. Right now, it is picking up Intermediates.ComputePassFlags from PostProcesFFTBloom which is set to ERDGPassFlags::AsyncCompute.
AddApplyLocalExposurePass(
GraphBuilder,
View,
EyeAdaptationParameters,
EyeAdaptationBuffer,
LocalExposureParameters,
LocalExposureTexture,
BlurredLogLuminanceTexture,
Temp,
FFTInputSceneColor,
ERDGPassFlags::Compute);//Intermediates.ComputePassFlags);
Hello,
Thank you for reaching out.
I’ve been assigned this issue, and we will be looking into this synchronization issue for you.
Hello,
This issue was fixed by CL: 38602096 in //UE5/Main. This CL was included in Unreal Engine 5.5.1.
For more information, please see this ticket: [Content removed]
If you are experiencing this issue on the latest patch, please let us know.
Hi Stephen!
Thanks for the reply! We are on 5.5.4 and experiencing this issue.
The commit from the other thread is here: https://github.com/EpicGames/UnrealEngine/commit/538605b4c33e92a51095c1ea87c8bbe2696fcbcf.
However, it does not look like this commit is in the release branch that is currently at 5.5.4. https://github.com/EpicGames/UnrealEngine/blob/release/Engine/Source/Runtime/D3D12RHI/Private/D3D12CommandContext.cpp.
I can pull the commit into our branch and test it, but 5.5.4 does not have the fix yet.
Thanks!
Hello,
Thank you for the clarification. You are correct, the information from the linked ticket about the fix being included in 5.5.1 appears to be incorrect, and it is not included in other 5.5 release streams.
We informed Epic Games staff about the possible discrepancy in the other ticket.
Please let us know if backporting the changes resolves the issue for you.