google / google/filament

OpenGL rendering unusable on Intel Iris Xe

Open
#8,195 0 comments 0 reactions 1 assignee Claimed by @pixelflinger View on GitHub
gpu specific opengl
Dominant language
C++
Stars
20.5k
Forks
2.3k
Avg merge
2d 13h
Merged PRs (30d)
90

Description

⚠️ **Issues not using this template will be systematically closed.**

**Describe the bug**
Using the OpenGL renderer on my Intel Iris Xe chipset produces corrupt results, whereas the exact same binary looks correct in OpenGL on my NVIDIA 2080 Ti. Furthermore, the Vulkan backend produces correct result on both chips (Intel and NVIDIA).

The code isn't doing anything fancy. Basically I just followed the examples to build a very basic scene with a skybox/IBL and am rendering a .glb object.

**To Reproduce**
Steps to reproduce the behavior:
1. Run Filament in opengl mode on an Intel Iris Xe chip.

I used Renderdoc to capture a frame on the NVIDIA chip and the Intel chip. Here are the captures, which I think will be helpful to understand what's up:

https://static.anukari.com/blog-media/anukari-opengl-capture-bad.rdc
https://static.anukari.com/blog-media/anukari-opengl-capture-good.rdc

**Expected behavior**
Scene should look correct without corruption.

**Screenshots**
This screenshot shows what the good output is on my NVIDIA chip, taken from Renderdoc:
![Image](https://github.com/user-attachments/assets/b7edd1f9-8cea-43d6-83d7-ac72465d4d1e)

This screenshot shows what I get instead on the Intel chip.
![Image](https://github.com/user-attachments/assets/9500ef21-df58-401e-b07f-278af2a39d5e)

There are a couple of interesting things I noticed on the Intel chip:
1. If you look really closely, you can see a light red sphere on the black output, in the lower left quadrant. To my eyes, this looks like the depth buffer! And from playing with it, the depth buffer output is scaled to the lower left quadrant of the window. So while the sphere should be in the center of the viewport, it is showing up in the center of the lower left quadrant.
2. In the Color Pass in Renderdoc, note that the Intel chip has an extra call at the end to glDrawElementsInstance(3, 1). This is the skybox. On the NVIDIA chip it's drawn at the beginning only. On the Intel chip it's drawn at the beginning and end. It is the second call that corrupts the color pass output, for some reason.

**Logs**
Here are the logs on the machine where OpenGL rendering is corrupt:
```
FEngine (64 bits) created at 00000288C0ED0290 (threading is enabled)
FEngine resolved backend: OpenGL
[Intel], [Intel(R) Iris(R) Xe Graphics], [4.5.0 - Build 32.0.101.6079], [4.50 - Build 32.0.101.6079]
Feature level: 3
Active workarounds:
vao_doesnt_store_element_array_buffer_binding
allow_read_only_ancillary_feedback_loop
Backend feature level: 3
FEngine feature level: 1
```

Logs from the machine where OpenGL rendering works:
```
FEngine (64 bits) created at 000001EAAF4EE2E0 (threading is enabled)
FEngine resolved backend: OpenGL
[NVIDIA Corporation], [NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2], [4.5.0 NVIDIA 561.09], [4.50 NVIDIA]
Feature level: 3
Active workarounds:
allow_read_only_ancillary_feedback_loop
Backend feature level: 3
FEngine feature level: 1
```

**Desktop (please complete the following information):**
- OS: Windows 11
- GPU: [Intel], [Intel(R) Iris(R) Xe Graphics], [4.5.0 - Build 32.0.101.6079], [4.50 - Build 32.0.101.6079]
- Backend: OpenGL

**Smartphone (please complete the following information):**
- N/A

**Additional context**
N/A

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.