search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
87k stars 19.52k forks source link

Graphical glitches on windows with Intel Iris Xe graphics (3D render to texture, GLES3, batching disabled) #53147

Closed jamie-pate closed 1 year ago

jamie-pate commented 2 years ago

Godot version

v3.3.2.stable.official, v3.3.3.stable.official Happens with both Release (export) and tools builds.

System information

Windows 10, GLES3, Intel(R) Iris(R) Xe Graphics, i7-1165G7

Issue description

The screen is cleared occasionally and a solid color is shown instead. https://streamable.com/fqt18v

GLES3 i7-1165G7 Intel(R) Iris(R) Xe Graphics (uhd series and other vendors are not affected) DriverVersion: "27.20.100.9749", "30.0.100.9864" 1920 x 1080 x 4294967296 colors os_ver: "10.0.19042 N/A Build 19042",

Steps to reproduce

Seems like you need Viewports and gridmaps to reproduce....

Minimal reproduction project

see https://github.com/godotengine/godot/issues/53147#issuecomment-929771161

jamie-pate commented 2 years ago

Random guesses as to what's going wrong in the driver: The frustrum randomly gets set to 1.0x1.0 at the far plane? Sampling the intermediate viewport render target incorrectly?

lawnjelly commented 2 years ago

What are those moving lines around 1 - 2 second mark? Are you drawing something skinned? Could be a NaN or something creeping in with some dodgy data for an animation.

jamie-pate commented 2 years ago

The lines are links of the lanyard 'rope' that is only visible when you scan the key card in the door.

There is no skinning and the links are made of separate capsule mesh and rigid bodies, so the movement is mostly physics based. There's no animated skeletons. The only animation is a rigid body used to 'pull' the end of the chain. (I copied the chain on the tow truck in truck town)

I don't think it's related because that tree gets hidden after a few seconds and the glitch persists.. it seems to be related to where the camera is pointed as it stays on the screen when the player stops moving the mouse..

Luckily I have a line on a new laptop with the same hardware today so I will hopefully be able to reproduce and report an issue with the vendor.

NOTE: this only happens on the new iris xe gpus afaik

jamie-pate commented 2 years ago

Immediately reproduced on similar hardware with the same driver version.

Seems to be related to render target double buffering? Here are some more artifacts:

https://streamable.com/404xqx

image

One viewport (the door label) gets extra weird textures at the end...

Issue seems to mostly go away when a transparent ViewPort that's drawing the phone notifications gets drawn? so weird

Calinou commented 2 years ago

Seems to be related to render target double buffering? Here are some more artifacts:

Can you reproduce it if you disable V-Sync in the project settings and make sure the graphics driver doesn't force V-Sync on its end? You can set a FPS limit using the Force Fps project setting.

jamie-pate commented 2 years ago

interesting correlation with frame time ...this is with vsync off (unable to use gamebar to record when the editor is running?)

https://streamable.com/64gdn6

jamie-pate commented 2 years ago

hall of mirrors with the clear color in the editor image ... stopped after the screenshot?

jamie-pate commented 2 years ago

~Some of the problem seems to be linked to gpu particles?,... when I turn 'emitting true' it stops flickering? then starts again when it stops emitting.. but cpu/gpu particles don't change the outcome...~

If i move the particle system outside the mesh that contained them the flickering is still there no matter if they are playing or not.. maybe for some reason it's caused by this particular material having no visible fragments? :exploding_head: The flickering goes away once the viewport for this mesh has visible data written to it.

[sub_resource type="ViewportTexture" id=5]
flags = 4
viewport_path = NodePath("Viewport")

[node name="Viewport" type="Viewport" parent="."]
size = Vector2( 400, 500 )
transparent_bg = true
usage = 0
render_target_v_flip = true
gui_disable_input = true

[node name="MeshInstance2" type="MeshInstance" parent="Iphone"]
transform = Transform( -1, 0, -1.50996e-07, 0, 1, 0, 1.50996e-07, 0, -1, 0, 0.0724497, -0.00252686 )
cast_shadow = 0
mesh = SubResource( 4 )
material/0 = SubResource( 6 )

[sub_resource type="SpatialMaterial" id=6]
resource_local_to_scene = true
flags_transparent = true
flags_unshaded = true
flags_no_depth_test = true
flags_albedo_tex_force_srgb = true
flags_do_not_receive_shadows = true
flags_disable_ambient_light = true
params_depth_draw_mode = 2
params_line_width = 0.1
params_billboard_mode = 1
params_billboard_keep_scale = true
params_use_alpha_scissor = true
params_alpha_scissor_threshold = 0.01
albedo_texture = SubResource( 5 )
uv1_scale = Vector3( 1, 2, 1 )

image

I'm still trying to figure out how to reproduce this as my game has a bit of a weird setup. I'll try to explain by way of this video:

https://streamable.com/rrtp6a

In this video I have shrunk down the BackGround and ForeGround ViewportContainers, then made them visible. Normally they are not visible except when you open the menu. At that point I update all the canvas layers so that everything is drawn on the BackGround/ForeGround viewports instead of the root viewport.

In the video you can see that the scene drawn to the background viewport still draws the viewport texture wrong sometimes even though the root viewport seems ok with --frame-delay 200

jamie-pate commented 2 years ago

iris_xe_flicker_repro.zip

Finally got a cut down repro... for some reason it needs to include a gridmap...

run with --frame-delay 500 for best results

https://streamable.com/1lqb7q

and reported to intel 🤞 image

jamie-pate commented 2 years ago

https://streamable.com/0z49dg this is the reproduction in a uhd 630... Seems like it may be affected but not as badly? Only one viewport is flickering...

akien-mga commented 2 years ago

streamable.com/0z49dg this is the reproduction in a uhd 630... Seems like it may be affected but not as badly? Only one viewport is flickering...

I don't seem to reproduce the issue on Linux with Intel HD 630 and Mesa 21.2.2 - but that's not surprising. I'll see if I can reproduce it on Windows 10 whenever I find time to reboot :)

jamie-pate commented 2 years ago

~iris_xe_flicker_repro2.zip~ repro2 is from the wrong directory :flushed: iris_xe_flicker_repro3.zip

Another, more focused repro. I got rid of the player and phone and focused on the 3 elements that are apparentlyrequired to cause this:

  1. mesh with material that has a viewport texture
  2. viewport texture must have no opaque pixels
  3. Gridmap tile with transparent+refraction material
  4. many viewports? The issue is reproduced most frequently when the viewport spinbox is set around 15

https://streamable.com/ls6ifz video walkthrough:

0:10: Seems like buffers are not being flipped properly? this happens quite frequently with this reproduction 0:15..0:33: flipping the number in the spin box until one of the viewports draws incorrectly. 1:41: finally get a clean reproduction of the viewport being drawn as a single color 2:09: click on the 'viewport content' checkbox which appears to fix the buffer flipping. I can't reproduce the issue if there is content in this viewport texture 2:13: once I hide the viewport content it immediately starts flipping again 2:33: adding a copy of the gridmap's mesh (as a MeshInstance) also seems to prevent it from happening? 2:39: enable mouse/keyboard navigation control and spin around a bit to try to reproduce 2:53: hide the meshinstance copy of the gridmap content and it starts flipping again 2:57: hide the GridMap and it stops flipping 3:02 show gridmap, flipping :face_with_head_bandage:

jamie-pate commented 1 year ago

seems fixed in driver 31.0.101.3959!