[Latest Macbook Pro][Metal]renders blink severely

Hello,

There is a bug when use UE 4.15 on Latest 13inch Macbook Pro with Retina Screen.

Even the basic starter content, the main editor area is blinking all the times if use Metal API on Macbook Pro.

However if I force XCode use opengl to build UE4.15, everything is fine except the warning of deprecation of OpenGL on Mac.

Blink like this (really drive me crazy):

Videos Page:

http://ue.next.sh/

Videos:

http://ue.next.sh/ue_firstperson_initiative.mp4

http://ue.next.sh/ue_firstperson_move.mp4

http://ue.next.sh/ue_play.mp4

Thank you in advance

Found the malfunctioning part.

When I turn off the Show->Lighting Features->Indirect Lighting Cache, blink disappears.

When turn on this feature, blink starts.

Now I’m digging into code to locate the problem. If you are bothered by this problem and can not wait, just tun off Indirect Lighting Cache for now to finish all the job unrelated to Indirect Lighting Cache.

Hit play, if renders still are blinking. Then you can you console command(press ~, then you can input command):

ShowFlag.IndirectLightingCache 0

then blink stops


Collateral damage:

After I rebuild lights, blinks starts again. However console command does not work here. And it won’t stop until I reboot UE4 Editor.

I don’t know why, maybe light build progress will build with indirect lighting cache. So the viewport will ignore the show feature settings after it apply the result of light build.

Hope I can find the real solution in time

Hi LimboSix,

Thank you for submitting a bug report. I have reproduced the issue and logged it as UE-43725 which you can track on the following link: Unreal Engine Issues. Please be aware that since the issue must be reviewed and prioritized by our development staff, it may be a while before it can be addressed.

-.

There is a known issue with Intel GPU drivers. Try turning Automatic Graphics Switching off in the following location: System Preferences>Energy Saver>Automatic Graphics Switching: make sure box is unchecked.

Let me know if this does not resolve the issue.

Thanks. However, my 13inch won’t have that option because it only has one GPU, so it can’t do any switching. The 13 inch only comes with the integrated GPU and no discrete GPU, so it doesn’t have automatic graphics switching option.
Intel Iris Graphics 550:

  Chipset Model:	Intel Iris Graphics 550
  Type:	GPU
  Bus:	Built-In
  VRAM (Dynamic, Max):	1536 MB
  Vendor:	Intel (0x8086)
  Device ID:	0x1927
  Revision ID:	0x000a
  Metal:	Supported
  Displays:
      Color LCD:
        Display Type:	Built-In Retina LCD
        Resolution:	2560 x 1600 Retina
        Pixel Depth:	32-Bit Color (ARGB8888)
        Main Display:	Yes
        Mirror:	Off
        Online:	Yes
        Rotation:	Supported
        Automatically Adjust Brightness:	Yes
        Connection Type:	DisplayPort

I have located one possible line which could lead to this problem.
In file: ./Engine/Source/Runtime/Engine/Private/PrimitiveDrawingUtils.cpp
Line 1319: !ViewFamily.EngineShowFlags.IndirectLightingCache || in method bool IsRichView(const FSceneViewFamily& ViewFamily);

When I change this line into ViewFamily.EngineShowFlags.IndirectLightingCache || which force IsRichView to true if IndirectLightingCache is set or move ViewFamily.EngineShowFlags.IndirectLightingCache || into next IF block, rebuild UE4.15 with Xcode. And blink stops.

Why a view is rich if is missing the EngineShowFlags.IndirectLightingCache? Shouldn’t be reversed? Isn’t IndirectLightingCache a rich view feature?

And still, it won’t solve the collateral damage mentioned in the last answer this page. After I rebuild lights, blinks starts again.

Another Question: what happens after I click build light only?

.
.
.

PS:

Also there should be several new Clang Diagnostic ignored entries in file ./Engine/Source/Runtime/Core/Public/Mac/MacPlatformCompilerPreSetup.h after upgrade Xcode to Version 8.3 (8E162). Or it will lead to build failure.

I believe it should be :

#pragma clang diagnostic ignored "-Wnullability-inferred-on-nested-type"

#pragma clang diagnostic ignored "-Wobjc-protocol-property-synthesis"

#ifndef PRAGMA_DISABLE_UNDEFINED_IDENTIFIER_WARNINGS

#define PRAGMA_DISABLE_UNDEFINED_IDENTIFIER_WARNINGS \

_Pragma("clang diagnostic push") \

_Pragma("clang diagnostic ignored \"-Wundef\"") \

_Pragma("clang diagnostic ignored \"-Wnull-dereference\"")

#endif // PRAGMA_DISABLE_UNDEFINED_IDENTIFIER_WARNINGS

Conclusion:

If !ViewFamily.EngineShowFlags.IndirectLightingCache ||, in file: ./Engine/Source/Runtime/Engine/Private/PrimitiveDrawingUtils.cpp Line 1319,

is correct, a view is rich if is missing the EngineShowFlags.IndirectLightingCache.

Then something needs to fix in FPositionOnlyDepthDrawingPolicy in file ./Engine/Source/Runtime/Renderer/Private/DepthRendering.cpp;

In file./Engine/Source/Runtime/Renderer/Private/DepthRendering.cpp Line 512,

one of paramter VertexDeclaration should take the blame for this bug. Because if I replace this VertexDeclaration with FMeshDrawingPolicy::GetVertexDeclaration() which directly use method in the base class of FPositionOnlyDepthDrawingPolicy, blink stops.

This time, the collateral damage is also fixed!!! Even after I apply build light only, there is no blink or black screen


Deduction:

If !ViewFamily.EngineShowFlags.IndirectLightingCache ||, in file: ./Engine/Source/Runtime/Engine/Private/PrimitiveDrawingUtils.cpp Line 1319,

is correct.

If set Result.bStaticRelevance = true; in File ./Engine/Source/Runtime/Engine/Private/StaticMeshRender.cpp Line 1225, blink starts no matter what value Result.bDynamicRelevance is.

Located in File /Engine/Source/Runtime/Renderer/Private/SceneVisibility.cpp Line 1755 function ComputeAndMarkRelevanceForViewParallel triggers this bug.

Because if bStaticRelevance = true in StaticMeshRender.cpp, this will lead to RelevantStaticPrimitives.AddPrim(BitIndex); in SceneVisibility.cpp#Line1495 when ComputeRelevance is called.

And then after function MarkRelevant is called which makes MarkMasks[StaticMesh.Id] = MarkMask;.

But in the end, it is static method static void ComputeAndMarkRelevanceForViewParallel fired this two functions, ComputeRelevance and MarkRelevant.

So in the ComputeAndMarkRelevanceForViewParallel, if this bit, StaticMeshOccluderMap_Word |= (MaskMask & EMarkMaskBits::StaticMeshOccluderMapMask) ? Mask : 0;, sets, will lead to the bug.

=> Blink stops if remove Line 931, bDirty |= Scene->PositionOnlyDepthDrawList.DrawVisible(RHICmdList, View, DrawRenderState, View.StaticMeshOccluderMap, View.StaticMeshBatchVisibility);, in file ./Engine/Source/Runtime/Renderer/Private/DepthRendering.cpp;

=> Which leaves us a policy, FPositionOnlyDepthDrawingPolicy in the same file DepthRendering.cpp.

=> Finally, return FBoundShaderStateInput(VertexDeclaration, VertexShader->GetVertexShader(), FHullShaderRHIRef(), FDomainShaderRHIRef(), FPixelShaderRHIRef(), FGeometryShaderRHIRef());

In file./Engine/Source/Runtime/Renderer/Private/DepthRendering.cpp

Line 512, one of paramter VertexDeclaration should take the blame for this bug. Because if I replace this VertexDeclaration with FMeshDrawingPolicy::GetVertexDeclaration() which directly use method in the base class of FPositionOnlyDepthDrawingPolicy, blink stops.

I know the actual problem may be in VertexFactory->GetPositionDeclaration(), however I am gonna stop here waiting for official fixes.

Hope this track can be helpful.


For those who can not wait for the official fixes:

Please ignore all my other comments and answers above this line in this page In file./Engine/Source/Runtime/Renderer/Private/DepthRendering.cpp Line 512, replace VertexDeclaration with FMeshDrawingPolicy::GetVertexDeclaration(), blink stops!

Warning: This replacement isn’t a best solution or even a solution and also may affect other functionality, even though it fixes this bug superficially. Please wait official bug fix if you encounter side effects

Thank you for the additional information. I have added this to the bug report.

I have the same problem here with )
The OS is macOS 10.12.3.

But the issue remains even I turn off the “Indirect Lighting Cache”. Is it another issue?

I have this issue only in 4.15.1, when switch back to 4.14.3, things become OK.

Thank you for this additional information. I have added it to the bug report (below) UE-43725.