Deadlock in FFastGeoComponentCluster::ForceUpdateVisibility Part 2

Development Pipeline & Plugins
, ,
1

This question was created in reference to: [Deadlock in [Content removed][Attachment Removed]

2

Dinner-Switch2-Test.nss!FPrimitiveSceneInfo::IsIndexValid(const FPrimitiveSceneInfo * this) Line 469 C++

Dinner-Switch2-Test.nss!FFastGeoComponentCluster::UpdateVisibility_Internal(TArray<FFastGeoPrimitiveComponent*, TSizedDefaultAllocator<32> >&&, TArray<FFastGeoPrimitiveComponent*, TSizedDefaultAllocator<32> >&&, int)::$_0::operator()(FRHICommandListBase&)::{lambda(TArray<FFastGeoPrimitiveComponent*, TSizedDefaultAllocator<32> >&, bool)#1}::operator()(TArray<FFastGeoPrimitiveComponent*, TSizedDefaultAllocator<32> >&, bool) const(bool bShow) Line 183 C++

Dinner-Switch2-Test.nss!FFastGeoComponentCluster::UpdateVisibility_Internal(TArray<FFastGeoPrimitiveComponent*, TSizedDefaultAllocator<32> >&&, TArray<FFastGeoPrimitiveComponent*, TSizedDefaultAllocator<32> >&&, int)::$_0::operator()(FRHICommandListBase&)(class {…} * this) Line 196 C++

Dinner-Switch2-Test.nss!UE::Core::Private::Function::TFunctionRefBase<UE::Core::Private::Function::TFunctionStorage<true>, void (FRHICommandListImmediate&)>::operator()(FRHICommandListImmediate&) const(const UE::Core::Private::Function::TFunctionRefBase<UE::Core::Private::Function::TFunctionStorage<true>, void (FRHICommandListImmediate &)> * this, FRHICommandListImmediate & Params) Line 471 C++

Dinner-Switch2-Test.nss!FRenderThreadCommandPipe::EnqueueAndLaunch(char16_t const*, unsigned int&, TStatId, TUniqueFunction<void (FRHICommandListImmediate&)>&&)::$_0::operator()() const() Line 1546 C++

Dinner-Switch2-Test.nss!Invoke<FRenderThreadCommandPipe::EnqueueAndLaunch(char16_t const*, unsigned int&, TStatId, TUniqueFunction<void (FRHICommandListImmediate&)>&&)::$_0&>(FRenderThreadCommandPipe::EnqueueAndLaunch(char16_t const*, unsigned int&, TStatId, TUniqueFunction<void (FRHICommandListImmediate&)>&&)::$_0&)() Line 47 C++

Dinner-Switch2-Test.nss!UE::Core::Private::Function::TFunctionRefCaller<FRenderThreadCommandPipe::EnqueueAndLaunch(char16_t const*, unsigned int&, TStatId, TUniqueFunction<void (FRHICommandListImmediate&)>&&)::$_0, void>::Call(void*)(void * Obj) Line 316 C++

Dinner-Switch2-Test.nss!UE::Core::Private::Function::TFunctionRefBase<UE::Core::Private::Function::TFunctionStorage<true>, void ()>::operator()() const(const UE::Core::Private::Function::TFunctionRefBase<UE::Core::Private::Function::TFunctionStorage<true>, void ()> * this) Line 471 C++

Dinner-Switch2-Test.nss!TFunctionGraphTaskImpl<void (), (ESubsequentsMode::Type)0>::DoTaskImpl(TUniqueFunction<void ()>&, ENamedThreads::Type, TRefCountPtr<FBaseGraphTask> const&)(TUniqueFunction<void ()> & Function) Line 1111 C++

Dinner-Switch2-Test.nss!TFunctionGraphTaskImpl<void (), (ESubsequentsMode::Type)0>::DoTask(ENamedThreads::Type, TRefCountPtr<FBaseGraphTask> const&)(TFunctionGraphTaskImpl<void (), (ESubsequentsMode::Type)0> * this) Line 1104 C++

Dinner-Switch2-Test.nss!TGraphTask<TFunctionGraphTaskImpl<void (), (ESubsequentsMode::Type)0> >::ExecuteTask()(TGraphTask<TFunctionGraphTaskImpl<void (), (ESubsequentsMode::Type)0> > * this) Line 706 C++

Dinner-Switch2-Test.nss!UE::Tasks::Private::FTaskBase::TryExecuteTask(UE::Tasks::Private::FTaskBase * this) Line 537 C++

Dinner-Switch2-Test.nss!FBaseGraphTask::Execute(FBaseGraphTask * this, bool bDeleteOnCompletion) Line 505 C++

Dinner-Switch2-Test.nss!FNamedTaskThread::ProcessTasksNamedThread(FNamedTaskThread * this, int32 QueueIndex, bool bAllowStall) Line 779 C++

Dinner-Switch2-Test.nss!FNamedTaskThread::ProcessTasksUntilQuit(FNamedTaskThread * this, int32 QueueIndex) Line 667 C++

Dinner-Switch2-Test.nss!RenderingThreadMain(FEvent * TaskGraphBoundSyncEvent) Line 318 C++

Dinner-Switch2-Test.nss!FRenderingThread::Run(FRenderingThread * this) Line 476 C++

Dinner-Switch2-Test.nss!FNintendoRunnableThread::Run(FNintendoRunnableThread * this) Line 159 C++

> [Unknown/Just-In-Time compiled code]

[Attachment Removed]

3

[Richard [Content removed] I’m wondering if we actually need your larger proposed change from the last support request? We are only seeing this on one platform which is slower on average than the others due to reduced core count.

Or an idea I’ve asked about before is if we should be trying to update and take the latest version of FastGeo? My I did previously look at this and it needed a couple of other changes to the world partition system which we would need guidance on knowing how much needed to be patched over?

[Attachment Removed]

4

Hi Sam,

Sorry to hear that you still have a deadlock.

Looking at the callstack, I don’t see where the dead lock happens.

Can you paste the 2 callstacks thanks.

Richard

[Attachment Removed]

5

So we found that we needed this, it was a soft lock stuck in a infinite loop:

bool FFastGeoPrimitiveComponent::IsDrawnInGame() const

{

//== TTGames : Fix FastGeo infinite hang ==

// Check that the primitive hasn’t been forcefully hidden which will prevent the proxy from being assigned to the GPU scene and will cause

// an infinite loop where the FFastGeoComponentCluster keeps trying to update the visibility.

if (GetSceneProxy() && GetSceneProxy()->IsForceHidden())

{

return false;

}

// == ~TTGames : Fix FastGeo infinite hang ==

[Attachment Removed]

6

Hi Sam, can you go into more details of the infinite loop?

I assume you are hitting the case where FFastGeoComponentCluster::UpdateVisibility_Internal always ends up filling elements into NotReadyComponents?

If so, I’d like to better understand what other thread(s) is/are block/waiting for the UpdateVisibility to finish.

Richard

[Attachment Removed]

7

Hi Sam, any more details would help better understand your issue.

Thanks,

Richard

[Attachment Removed]