Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Surface formats guaranteed by WebGPU may not be supported on GLES #1925

Open
Herschel opened this issue Sep 8, 2021 · 1 comment
Open

Surface formats guaranteed by WebGPU may not be supported on GLES #1925

Herschel opened this issue Sep 8, 2021 · 1 comment
Labels
area: documentation Documentation for crate items, public or private backend: gles Issues with GLES or WebGL help required We need community help to make this happen. type: bug Something isn't working

Comments

@Herschel
Copy link
Contributor

Herschel commented Sep 8, 2021

Description
The WebGPU spec guarantees the features of various texture formats, and these features are baked-in as supported by wgpu, and are returned by
Adapter::get_texture_format_features.

Additionally SurfaceConfiguration::format metions that Bgra8Unorm and Bgra8UnormSrgb are guaranteed to be supported.

However, the GL backend disagrees and, for example, may only support sRGB surfaces. Attempting to create the surface with an unsupported non-sRGB format will fail, even though there is no way to query what surface formats are truly supported by the backend.

Repro steps
Edit the hello-triangle example to use the GL backend:
let instance = wgpu::Instance::new(wgpu::Backends::GL);

Output this after adapter creation:
dbg!(adapter.get_texture_format_features(wgpu::TextureFormat::Bgra8Unorm));

Also replace the swapchain format:
let swapchain_format = surface.get_preferred_format(&adapter).unwrap();

Expected vs observed behavior
Observed:
The format is returned with various allowed usages:

adapter.get_texture_format_features(wgpu::TextureFormat::Bgra8Unorm) = TextureFormatFeatures {
    allowed_usages: COPY_SRC | COPY_DST | TEXTURE_BINDING | RENDER_ATTACHMENT,
    flags: (empty),
    filterable: true,
}

However, the GL backend with certain hardware fails when actually trying to use this format for the surface:
requested format Bgra8Unorm is not in list of supported formats: [Rgba8UnormSrgb, Bgra8UnormSrgb]

There's currently no way to query whether a specific surface format is supported by the backend.

Surface::get_preferred_format does correctly return TextureFormat::Bgra8UnormSrgb in this case, but it's possible the user wants to explicitly query whether a non-sRGB format if available.

Expected:
There should be an API to query which formats are actually supported by the surface.

SurfaceConfiguration docs could be updated to specify that Bgra8Unorm and Bgra8UnormSrgb are not guaranteed on all backends.

Extra materials
Sample repo:
https://github.com/Herschel/wgpu/tree/gl-tex-format
cargo run --example hello_triangle
wgpu @ 76bcd9c

Platform
OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.41.0, 5.13.13-200.fc34.x86_64, LLVM 12.0.1)

@kvark kvark changed the title Texture formats guaranteed by WebGPU may not be supported by all backends Surface formats guaranteed by WebGPU may not be supported on GLES Sep 8, 2021
@kvark kvark added area: api Issues related to API surface help required We need community help to make this happen. type: bug Something isn't working labels Sep 8, 2021
@teoxoy teoxoy added the backend: gles Issues with GLES or WebGL label Feb 24, 2023
@cwfitzgerald
Copy link
Member

This is a documentation issue.

@teoxoy teoxoy added area: documentation Documentation for crate items, public or private and removed area: api Issues related to API surface labels Nov 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: documentation Documentation for crate items, public or private backend: gles Issues with GLES or WebGL help required We need community help to make this happen. type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants