Incorrect SDF deactivation on Strix Halo results in flat/washed-out lighting.

Development Rendering
, ,
1

Issue: Unreal Engine incorrectly disables Signed Distance Field (SDF) generation on AMD Strix Halo, leading to flat/washed-out lighting and broken Lumen behavior in SM5.

Root Cause: The issue stems from a legacy hardware check in the engine’s RHI/Distance Field logic. The engine currently uses a blanket check to disable SDFs on integrated GPUs unless they are running Shader Model 6.

While this logic historically protected low-power integrated chips from performance exhaustion, Strix Halo possesses the compute and memory bandwidth to handle SDF generation comfortably. When running in SM5, the engine triggers this branch, returns false, and skips SDF generation entirely

Impact:

  • Scenes appear “flat” with no Ambient Occlusion or detailed Lumen shadowing.
  • Visual parity is broken between high-end APUs and discrete GPUs of similar compute capability.

Validation / Workarounds tested:

  1. SM6 Force: Forcing the project to Shader Model 6 resolves the issue, as it bypasses the GMaxRHIFeatureLevel < SM6 check. (Confirmed working on native Linux builds).
  2. RHI Override: Manually recompiling the engine to force GRHIDeviceIsIntegrated = false restores correct lighting and SDF generation on the hardware.
  3. Visualization: Using "r.DistanceFieldAO.VisualizeMeshDistanceFields 1" in SM5 shows an empty/missing SDF scene, whereas SM6 shows a fully populated scene.

Ask: Might the Rendering team reconsider this blanket GRHIDeviceIsIntegrated check for high-performance APUs?

Is there a plan to update this logic to use a more granular performance threshold (or an allowlist of Device IDs) so that next-gen integrated silicon isn’t penalized by legacy, SM5 safety checks?

Relevant code snippet:

if (GRHIDeviceIsIntegrated && GMaxRHIFeatureLevel < ERHIFeatureLevel::SM6)
{
  // In case of iGPU we use the maximum feature level to differentiate between older and newer more capable iGPU
  return false;
}

[Attachment Removed]

2

Steps to Reproduce

Hardware Requirement: This issue is hardware-dependent and requires an AMD Strix Halo APU.

Project Setup: Any standard UE 5.6 project with Lumen and Generate Mesh Distance Fields enabled in Project Settings.

  1. Launch: Run the project on Strix Halo hardware using the SM5 (Shader Model 5) RHI.
  2. Observe: Lighting will appear flat/washed out.
  3. Verify via Console: Enter “r.DistanceFieldAO.VisualizeMeshDistanceFields 1”
    1. Notice the visualization will be empty.
  4. Comparison: Switch the RHI to SM6 or override GRHIDeviceIsIntegrated to false in source and restart.
    1. Observe that the Distance Field Scene now populates correctly and lighting is restored.
      [Attachment Removed]
3

We encountered this a while back and ended up adding a modification to distinguish GRHIDeviceIsIntegratedIntelHD so that we could only blacklist problematic Intel HD iGPUs which is what the original motivation for the engine code seemed to be (see: [Content removed]

We simply do

FString AdapterName = FString(ChosenAdapters[0].Get()->GetDesc().Desc.Description);
bool bContainsIntel = AdapterName.Contains(TEXT("intel"), ESearchCase::IgnoreCase);
bool bContainsHD = AdapterName.Contains(TEXT("hd"), ESearchCase::IgnoreCase);
bool bContainsUHD = AdapterName.Contains(TEXT("uhd"), ESearchCase::IgnoreCase);
GRHIDeviceIsIntegratedIntelHD = bContainsIntel && bContainsHD && !bContainsUHD;

in FD3D12DynamicRHIModule::CreateRHI().

Would be interested if Epic has any plans for a more granular system though.

[Attachment Removed]

4

Hi,

We don’t have plans to introduce a more granular performance threshold in this area but the code referenced above was removed in (UE 5.8) for similar reasons:

CL#48101768 Distance Fields - allow distance fields to run on GRHIDeviceIsIntegrated. This check was added a decade ago to prevent issues on some outdated drivers, but nowadays it prevents some pretty capable SM5 GPUs to run distance field features.

[Attachment Removed]