SDFGI broken with Intel Arc a750

[MikeLundahl]

Tested versions

4.2.1 and 4.1.1

System information

Godot v4.2.1.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated Intel(R) Arc(TM) A750 Graphics (Intel Corporation; 31.0.101.5382) - 13th Gen Intel(R) Core(TM) i7-13700K (24 Threads)

Issue description

On intel Arc a750 gpu, the global illumination gets blown out when there's roughness. When roughness is either 0 (or close to 0) or 100% (or close to 100%) it fades away.

Simple demo scene in 4.2.1 GI on

GI off

Video showing the effect https://github.com/godotengine/godot/assets/42893106/bb03b3ac-a028-4a35-aaed-30d73eb78fe7

Game project being worked on in 4.1.1 GI on

GI off

How game should look like (on Nvidia 1070Ti) https://vimeo.com/914046747/1ae8b3389e?share=copy

Steps to reproduce

1. Make sure to have an Intel Arc a series card (I have a750)
2. create a simple 3d scene
3. Create an environment
4. create a mesh and apply standard material
5. Switch on SDFGI
6. Drag the roughness slider to see effect.

Minimal reproduction project (MRP)

Test scene test.zip

[octanejohn]

maybe test 4.3 dev also check dx12 https://github.com/godotengine/godot-builds/releases/download/4.3-dev5/Godot_v4.3-dev5_win64.exe.zip

[MikeLundahl]

Thanks John. I downloaded the version you linked to and opened up the test scene.. same issue I'm afraid

[octanejohn]

what about dx12?

[MikeLundahl]

I try to switch to dx12, Godot asks me to save and restart Godot.. I do that.. Now I can't open the scene at all, Godot crashes before the project loads. This both happened on the test scene and a brand new scene in 4.3 dev 5

[octanejohn]

did you extract the dxil.dll from dxc and put it next to the godot exe?

[MikeLundahl]

There were no such file in the zip you linked to.. Where can I find it?

[octanejohn]

the docs has a step by step, the link is this https://github.com/microsoft/DirectXShaderCompiler/releases/download/v1.8.2403.2/dxc_2024_03_29.zip

[MikeLundahl]

Thanks! Found the dxil.dll and put it next to godot.exe. Now I can open Godot with Dx12. Unfortunately.. still same issue

[octanejohn]

the only alternative i know is to test on linux to see if its hardware issue or engine issue if not wait for the devs to check, also make sure is lauching with dx12 from the error tab because you have to change to dx12 from the driver tab maybe

[MikeLundahl]

Hardware seems to be fine (i've tested other games and had no issues, and the card is just a few days old). Or do you mean the intel drivers?

[octanejohn]

the picture you linked it says the driver is still vulkan i think make sure from the error tab it says is dx12 or maybe i am blind

[octanejohn]

4.3 it was a rendering rewrite so maybe this is a intel windows driver issue

[MikeLundahl]

Well. I changed it for windows (since I'm on windows.).. but here I changed it for all. Not sure what you mean by the error tab.

[octanejohn]

maybe change glow or camera atribute practical to physical after that i am out of ideas

[MikeLundahl]

This might be a dumb question. But what does the discussion tag mean?

[MikeLundahl]

maybe change glow or camera atribute practical to physical after that i am out of ideas

Yeah, no. This is definitely not a "settings" issue. I'm afraid there's no setting that can tweak this to look good or behave correctly.

I've also upgraded to Windows 11. Made no difference.

[Calinou]

It might be worth checking whether HDDAGI has this issue: https://github.com/godotengine/godot/pull/86267

HDDAGI is slated to replace SDFGI in the long run (after 4.3).

[MikeLundahl]

It might be worth checking whether HDDAGI has this issue: #86267

HDDAGI is slated to replace SDFGI in the long run (after 4.3).

So I did just that and tried the creating a new build to test HDDAGI.

This seems to work better and doesn't blow out.

[MikeLundahl]

I also opened up my earlier scene to test HDDAGI

There are some places that seem to have some normal or shading issues (doesn't seem to be related to HDDAGI as it's also there when turning it off)

So, if this works, does it mean that it's potentially not a driver issue?

[Calinou]

Good to see HDDAGI works on Arc :slightly_smiling_face:

So, if this works, does it mean that it's potentially not a driver issue?

The normal/shading issues may be related to the source mesh data not having correct normals, rather than a Godot rendering issue. Could you upload the source scene somewhere?

There's a debug draw mode you can use to check the normals in the scene: Debug Advanced > Normal Buffer in the 3D viewport's Perspective menu. You could also take a screenshot with this debug draw mode and upload it here.

[MikeLundahl]

The normal/shading issues may be related to the source mesh data not having correct normals, rather than a Godot rendering issue. Could you upload the source scene somewhere?

Unfortunately I can't share that exact scene as it's a project I'm working on. But I can try and replicate the issue with other assets and a more simple scene.

There's a debug draw mode you can use to check the normals in the scene: Debug Advanced > Normal Buffer in the 3D viewport's Perspective menu. You could also take a screenshot with this debug draw mode and upload it here.

This is what I got

[MikeLundahl]

When I asked about this potentially not being a driver issue, I was referring more to the GI issue than the normal shading.

Reason I asked about the driver is if this is something that can be fixed on the engine, or if this is something that Intel needs to fix.

[Calinou]

This is what I got

Is MSAA 3D enabled in the project settings? If so, try disabling it. It's known to break the normal buffer debug draw mode until https://github.com/godotengine/godot/pull/91808 was merged (which isn't in 4.3.dev6, only in recent master).

[MikeLundahl]

Is MSAA 3D enabled in the project settings? If so, try disabling it.

Tried it and it worked. @Calinou

Here's how the normal looks like in the HDDAGI branch

And in Godot 4.1.1 it looks as it should

[MikeLundahl]

Any chance this might be looked into for SDFGI? If HDDAGI is planned for 4.4, I suspect it might take a very long time for the arc cards to be usable for 3D games with GI.

[Calinou]

Any chance this might be looked into for SDFGI?

Unfortunately, I don't think so, as none of the rendering contributors have access to Intel Arc GPUs to my knowledge. This hardware isn't particularly widespread after all, especially since many prospective buyers are waiting for Battlemage (the generation of Arc GPUs after the current Alchemist).

In the meantime, you'll probably have a better experience on Linux where Arc GPUs benefit from the Mesa infrastructure in a way the Windows drivers don't. This means having access to much more reliable Vulkan and OpenGL implementations, with DXVK being well-supported too.

[MikeLundahl]

That's very unfortunate if that's the case.

Feels like this is something with the exposure or colorspace connected to the roughness/reflection shading? I could be wrong as I'm not a rendering programmer. But since I do have the GPU, maybe I can have a look into this and see if it's something that's semi easy to solve.

If any rendering expert sees this. What would be a good place for me to start looking? Any guesses on what might be causing this?

[Calinou]

If any rendering expert sees this. What would be a good place for me to start looking? Any guesses on what might be causing this?

You could run Godot through RenderDoc to step through the rendering process (make sure to use a debug build of the engine compiled with the dev_build=yes SCons option). There might be something strange you can notice when stepping through. RenderDoc capture files are not interoperable across GPUs, so we can't replay them locally, but you can record a video of yourself going through the capture step-by-step.

[MikeLundahl]

Thanks! I will have a look at that.

[MikeLundahl]

Just did a quick test with renderdoc (4.2.2 dev build). Could it be something with the reflection buffer?