Linux with GLES <3.2: Bevy 3D rendering does not work, due to Cubemap Array Textures

[inodentry]

Bevy version

Current main, commit d6d25d8

Relevant system information

Hardware: Apple M1 Pro, 14in MacBook Pro

OS: Asahi Linux
Drivers: mesa-asahi-edge-23.2.0_pre20230606-1
Kernel: linux-asahi-edge-6.3.asahi7-1

AdapterInfo { name: "Apple M1 Pro (G13S C0)", vendor: 65541, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Gl }

SystemInfo { os: "Linux  Arch Linux ARM", kernel: "6.3.0-asahi-7-1-edge-ARCH", cpu: "Icestorm-M1-Pro", core_count: "10", memory: "31.0 GiB" }

What you did

Run any bevy 3D example.

cargo r --features wayland --example load_gltf

(note: wayland is required, see #8788)

What went wrong

Panic on wgpu error:

2023-06-08T09:29:29.451613Z ERROR wgpu_hal::gles::egl: GLES: [API/Error] ID 1 : GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
2023-06-08T09:29:29.451670Z ERROR wgpu_hal::gles::egl: GLES: [API/Error] ID 1 : GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
2023-06-08T09:29:29.539334Z ERROR wgpu::backend::direct: Shader translation error for stage ShaderStages(NONE | VERTEX): The selected version doesn't support CUBE_TEXTURES_ARRAY
2023-06-08T09:29:29.539366Z ERROR wgpu::backend::direct: Please report it to https://github.com/gfx-rs/naga
2023-06-08T09:29:29.539392Z ERROR wgpu::backend::direct: Handling wgpu errors as fatal by default
thread 'Compute Task Pool (1)' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_render_pipeline
      note: label = `alpha_blend_mesh_pipeline`
    Internal error in ShaderStages(NONE | VERTEX) shader: The selected version doesn't support CUBE_TEXTURES_ARRAY

', /home/ida/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.16.1/src/backend/direct.rs:3019:5

The panic occurs on the frame when the first 3D entity is spawned, as that is when Bevy attempts to create the Render Pipeline via the Pipeline Cache. If running the load_gltf example, we can see that the app runs for a while, displaying an empty window, while waiting for the GLTF asset to load, and then the crash occurs.

Additional information

Asahi Linux does not yet have a Vulkan driver, so Bevy has to run via the fallback GL wgpu backend, which uses GLES3. GLES 3.0 support was just added to the Asahi GPU drivers.

Cubemap Array Textures are an extension (GL_OES_texture_cube_map_array) that is included in GLES 3.2. As we can see in Mesa Matrix, it is not supported on Asahi, and also in plenty of other drivers for that matter.

Bevy requiring cubemap array textures to do any kind of 3D rendering is bad, as it limits platform compatibility. It prevents Bevy 3D apps from running on any of these drivers. This also includes Raspberry Pis and other embedded/mobile hardware.

I think Bevy should relax this requirement. Cubemap Array Textures (whatever bevy uses them for, I don't know, I am assuming environment map lighting) should be made optional by putting them behind shader defs / pipeline specialization.

It should be possible for Bevy users to make 3D apps that can run on such platforms, as long as they don't use the fancy rendering features that need this texture type.

Bevy 2D rendering works fine on Asahi. I am able to successfully run 2D examples and apps.

---

Edit: no longer an issue on Asahi, since Asahi provides GLES 3.2 compliant drivers now and all the relevant features are supported. May still be an issue on other systems/hardware/drivers.

[JMS55]

This is due to EnvironmentMapLight requiring a cubemap texture. We'll have to put it behind an ifdef, perhaps as a separate bind group, and add a docs warning about lack of GL support on some platforms, with a note on how to check for compatibility at runtime.

[bjorn3]

Looks like we already have #ifdef NO_ARRAY_TEXTURES_SUPPORT elsewhere. I can't find anything about EnvironmentMapLight requiring a texture cube map array. It lists TextureViewDimension::Cube, not TextureViewDimension::CubeArray in get_bind_group_layout_entries.

[JMS55]

Ah your right, I misread it. I think the actual issue is probably point_light_shadow_map_array_texture_view. On non webgl+wasm platforms, it uses a CubeArray. We probably need to add a check for that for feature support, and not just assume it works.

[inodentry]

I want to point out that this is no longer an issue on Asahi, because Asahi has now been offering full featured and compliant drivers for all the latest versions of GL and GLES, for quite a while. I have been happily using Bevy 0.13 with 3D rendering just fine. The only remaining noticeable issues are #13115 and that Bevy defaults to software/CPU Vulkan instead of GLES, unless I set WGPU_BACKEND=gl.

I do not have another system where the drivers only support GLES <3.2 to confirm if this issue is still present. If anyone can reproduce (maybe on some Arm SBC?), we will know if we should close this issue or keep it open.

That said, given that wide hardware compatibility is a goal of the Bevy project, it is a good idea for Bevy's renderer to check for feature support and not just assume that things are available.

[alice-i-cecile]

#12849 appears related: it seems like this was hitting old Android devices too.