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

Downlevel max_inter_stage_shader_components not consistent #4298

Open
kpreid opened this issue Oct 25, 2023 · 3 comments
Open

Downlevel max_inter_stage_shader_components not consistent #4298

kpreid opened this issue Oct 25, 2023 · 3 comments
Labels
area: documentation Documentation for crate items, public or private

Comments

@kpreid
Copy link
Contributor

kpreid commented Oct 25, 2023

Description

The default values for Limits::max_inter_stage_shader_components are:

  • default = 60
  • downlevel_defaults = 60
  • downlevel_webgl2_defaults = 31

The limit to 31 was introduced by 2b985e2 #4248. But this does not make sense, because the documentation says that downlevel_defaults is the value for “…almost all backends, including “downlevel” backends such as OpenGL…”. So if the restriction is correct, it should be in downlevel_defaults too, not only in the WebGL-specific set.

Other non-bugfix improvements that could be made:

  • If that change is made, it would be useful to have a documented set of limits that fits WebGL2 only without trying to also fit other downlevel backends, since WebGL2 is still commonly the only option on web, so an application might want to be WebGL2 compatible without other constraints.
  • The documentation could clarify the distinctions between GL and GLES.

Platform

wgpu 0.18.0, macOS

@teoxoy teoxoy added the area: documentation Documentation for crate items, public or private label Dec 11, 2023
@teoxoy
Copy link
Member

teoxoy commented Dec 11, 2023

because the documentation says that downlevel_defaults is the value for “…almost all backends, including “downlevel” backends such as OpenGL…”

I can't seem to find this language. I think it's correct that the limits in downlevel_webgl2_defaults are lower than downlevel_defaults.

@kpreid
Copy link
Contributor Author

kpreid commented Dec 11, 2023

I can't seem to find this language.

Here:

wgpu/wgpu-types/src/lib.rs

Lines 956 to 959 in f7c8767

/// - [`Limits::downlevel_defaults()`]. This is a set of limits that is guaranteed to work on almost
/// all backends, including "downlevel" backends such as OpenGL and D3D11, other than WebGL. For
/// most applications we recommend using these limits, assuming they are high enough for your
/// application, and you do not intent to support WebGL.

I think it's correct that the limits in downlevel_webgl2_defaults are lower than downlevel_defaults.

As currently documented, yes. This issue is primarily about the fact that either Limits::downlevel_defaults().max_inter_stage_shader_components is too high (in which case this is not a documentation issue), or there is some further confusion. I'm not personally familiar with the actual backend implementation limits, so I don't know which of these is true.

Separately, I think that this simple principle no longer fits the complexity of reality, because "Web only" is an important use case. However, breaking that relationship is a more significant change; perhaps I should have filed a separate issue about it. Let's ignore that question and focus on fixing max_inter_stage_shader_components.

@teoxoy
Copy link
Member

teoxoy commented Dec 12, 2023

Looking some more into this, I think we should revert the change to max_inter_stage_shader_components.
OpenGL 3.1 doesn't require limits to have a minimum as far as I can tell, minimum limit requirements have been introduced in OpenGL 3.2. If people want to investigate and list the limits of OpenGL 3.1, those should go in a new downlevel_gl31_defaults.

A PR would be welcome.

cc @Zoxc @cwfitzgerald

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
Projects
None yet
Development

No branches or pull requests

2 participants