HZBOcclusion stalls renderthread on RHI flush

Development Rendering
, ,
1

I have hit a pretty lengthy stall here where the renderthread is waiting for a sigificantly long flush on the RHI. Is there a way to avoid this? I don’t mind grabbing older frame data if that’s why we’re doing this.

[Image Removed]

2

Hi there,

I’ve been looking into this and can see that this is caused by the following flush code in FDynamicRHI::RHIMapStagingSurface_RenderThread.

if (Fence == nullptr || !Fence->Poll() || Fence->NumPendingWriteCommands.GetValue() != 0)
{
   QUICK_SCOPE_CYCLE_COUNTER(STAT_RHIMETHOD_MapStagingSurface_Flush);
   RHICmdList.ImmediateFlush(EImmediateFlushType::FlushRHIThread);
}

I’m still investigating this a bit, but on consideration, have decided to make a bug report for this, as I doubt this large a stall was intentional. My guess is that this flush is here to support multiple RHIs, which might not have fence wait mechanisms. On D3D12, the call to GDynamicRHI->RHIMapStagingSurface, after the above code, already waits on the Fence, which should be sufficient. You can try changing the above code to the following:

if (Fence == nullptr)
{
   QUICK_SCOPE_CYCLE_COUNTER(STAT_RHIMETHOD_MapStagingSurface_Flush);
   RHICmdList.ImmediateFlush(EImmediateFlushType::FlushRHIThread);
}

And testing on all platform / RHIs you intend to release on to see if this is a viable solution for you.

Regards,

Lance Chaney

3

Public bug tracker now available here:

UE-347709

I recommend you vote on it to give it higher priority.

Regards,

Lance Chaney