Skip to content

Implement webgpu textureBindingViewDimension proposal to resolve texture view heuristics errors #8014

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.

Sign up for GitHub

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

Jump to bottom
Draft
wants to merge 2 commits into
base: trunk
Choose a base branch
from
Draft

Implement webgpu textureBindingViewDimension proposal to resolve texture view heuristics errors #8014

wants to merge 2 commits into from

Conversation

alextechcc
Copy link

@alextechcc alextechcc commented Jul 28, 2025 •
edited
Loading

Connections

Description

Fundamental issue is that webgpu's textures and texture views are incompatible with opengl's textures and texture views because they are mappings of vulkan's images and image views.

Originally posted by @tasogare3710 in #7428

Testing

  • Currently tested by replicating the error messages by creating a single layer D2Array and binding a texture view to it. Error is resolved and rendering is fixed. You can see this in the PR in examples/features/cube, I've disabled all examples except this one.
WGPU_BACKEND=gl cargo run --features gles --bin wgpu-examples cube

Squash or Rebase?

  • Not ready to be merged yet, undecided.

Checklist
(keeping, as draft)

  • Run cargo fmt.
  • Run taplo format.
  • Run cargo clippy --tests. If applicable, add:
    • --target wasm32-unknown-unknown
  • Run cargo xtask test to run tests.
  • If this contains user-facing changes, add a CHANGELOG.md entry.

MarijnS95 and others added 2 commits July 26, 2025 23:36
@MarijnS95
Allow optional RawDisplayHandle in InstanceDescriptor
21320be 
This allows platforms like GLES with EGL context backend to properly
initialize such that their `EGLDisplay` and `EGLContext` are compatible
with an incoming `Surface`, which is otherwise impossible if not for
hotpatching the context (and loosing all resources created on it) when a
surface comes in and that compositor connection becomes known.

This hotpatching is known to break quite a few systems and
initialization ordering (i.e. the alternative is forcing users to create
surfaces before querying adapters, which isn't feasible on platform like
Android), and is better avoided or at least made possible by using the
`(Raw)DisplayHandle` abstraction provided by `raw_display_handle` in the
way it's intended to be used (additionally, removing it from the surface
would be a sensible decision).

There may however be cases where users want to initialize multiple
`Instance`s or perhaps `Adapter`s for independent `RawDisplayHandle`s,
and certain backends may be designed specifically to cope with this
(i.e. Vulkan).

Note that this PR does nothing to address many other soundness problems
inside the EGL backend.
@alextechcc
DRAFT: Add textureBindingViewDimension compatibility mode to resolve …
e08b3f6 
…GLES texture view incompatibility
@alextechcc alextechcc requested review from crowlKats and a team as code owners July 28, 2025 00:05
@alextechcc alextechcc marked this pull request as draft July 28, 2025 00:06
@alextechcc
Copy link
Author

It's worth noting that this is currently a breaking change for every single create_texture call.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@crowlKats crowlKats Awaiting requested review from crowlKats crowlKats is a code owner

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@alextechcc @MarijnS95