Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add optional feature clip-distances #4588

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
Merged
merged 23 commits into from
May 29, 2024
Merged

Add optional feature clip-distances #4588

merged 23 commits into from
May 29, 2024

Conversation

Jiawei-Shao
Copy link
Contributor

@Jiawei-Shao Jiawei-Shao commented Apr 18, 2024 •
edited
Loading

This patch adds the optional feature clip-distances to WebGPU API and WGSL SPEC.

  • Add WebGPU API and WGSL optional feature clip-distances
  • Add new vertex stage output builtin variable clip_distances
  • Update the primitive clipping algorithm with user-defined clip distances
  • Add new validation rules to the validation algorithm on inter-stage interfaces when clip-distances is used in the vertex stage
  • Add new device limit maxClipDistancesSize and update the related vertex stage validation algorithm

Fixed: #390

@Jiawei-Shao
Add optional feature clip-distance
da59a39 
This patch adds the optional feature `clip-distance to WebGPU API
and WGSL SPEC.
- Add WebGPU API and WGSL optional feature `clip-distance`
- Add new vertex stage output builtin variable `clip-distance`
- Update the primitive clipping algorithm with user-defined clip
  distances
- Add new validation rules to the validation algorithm on
  inter-stage interfaces when `clip-distance` is used in the vertex
  stage
- Add new device limit `maxClipDistances` and update the related
  vertex stage validation algorithm
beaufortfrancois
beaufortfrancois reviewed Apr 18, 2024
View reviewed changes
Copy link
Contributor

@beaufortfrancois beaufortfrancois left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it would help developers if WGSL builtin value was renamed to clip_distances and WebGPU feature to "clip-distances".

@github-actions GitHub Actions
Copy link
Contributor

github-actions bot commented Apr 19, 2024 •
edited
Loading

Previews, as seen when this build job started (466c36f):
WebGPU webgpu.idl | Explainer | Correspondence Reference
WGSL grammar.js | wgsl.lalr.txt

@Jiawei-Shao
Copy link
Contributor Author

I believe it would help developers if WGSL builtin value was renamed to clip_distances and WebGPU feature to "clip-distances".

Done @beaufortfrancois

@Jiawei-Shao Jiawei-Shao requested review from Kangz, dneto0 and kdashg April 19, 2024 08:45
@beaufortfrancois
Copy link
Contributor

I believe it would help developers if WGSL builtin value was renamed to clip_distances and WebGPU feature to "clip-distances".

Done @beaufortfrancois

I'm still seeing singular "clip distance", not plural "clip distances".

@Jiawei-Shao
Copy link
Contributor Author

I believe it would help developers if WGSL builtin value was renamed to clip_distances and WebGPU feature to "clip-distances".

Done @beaufortfrancois

I'm still seeing singular "clip distance", not plural "clip distances".

Sorry @beaufortfrancois , now there should be no clip distance.

beaufortfrancois
beaufortfrancois reviewed Apr 19, 2024
View reviewed changes
@beaufortfrancois
Copy link
Contributor

I believe it would help developers if WGSL builtin value was renamed to clip_distances and WebGPU feature to "clip-distances".

Done @beaufortfrancois

I'm still seeing singular "clip distance", not plural "clip distances".

Sorry @beaufortfrancois , now there should be no clip distance.

You may want to edit #4588 (comment) and PR title as well.

beaufortfrancois
beaufortfrancois reviewed Apr 19, 2024
View reviewed changes
@Jiawei-Shao Jiawei-Shao changed the title Add optional feature clip-distance Add optional feature clip-distances Apr 22, 2024
@Jiawei-Shao
Copy link
Contributor Author

I believe it would help developers if WGSL builtin value was renamed to clip_distances and WebGPU feature to "clip-distances".

Done @beaufortfrancois

I'm still seeing singular "clip distance", not plural "clip distances".

Sorry @beaufortfrancois , now there should be no clip distance.

You may want to edit #4588 (comment) and PR title as well.

Done

@beaufortfrancois beaufortfrancois self-requested a review April 22, 2024 07:26
@Jiawei-Shao Jiawei-Shao requested a review from kainino0x April 23, 2024 05:55
kainino0x
kainino0x reviewed Apr 24, 2024
View reviewed changes
@kainino0x kainino0x mentioned this pull request Apr 30, 2024
Closed
alan-baker
alan-baker reviewed May 14, 2024
View reviewed changes
@Kangz
Copy link
Contributor

Kangz commented May 14, 2024

GPU Web WG 2024-05-08 Pacific-time
  • JS: One question is whether we should make the limit for number to 8, since that’s what Metal and D3D has as hardcoded.
  • KN: I think we could add a limit later if we wanted to. I think the downside is that if we ship this with the hardcoded limit, that might cause minor issues, but it’s very unlikely, because of the reasons you mentioned.
  • KG: Sounds reasonable to me
  • MW: Believe it’s indeed limited to 8 on Metal.
  • JS: I really want someone to review the WGSL side
  • KN: Everyone happy to land this feature, once details are ironed out?
  • KG: sounds like yes, and OK with hardcoding to 8.
  • Consensus: Hardcode max to 8, and we’ll review the WGSL side before landing.

kainino0x
kainino0x reviewed May 15, 2024
View reviewed changes
@Jiawei-Shao
Copy link
Contributor Author

Hi @kainino0x @alan-baker could you take a look at this PR?

kainino0x
kainino0x approved these changes May 18, 2024
View reviewed changes
Copy link
Contributor

@kainino0x kainino0x left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specs LGTM. I haven't dug into the backend investigations but it seems like the mapping is fairly straightforward. Still, what is the status of prototyping and testing? It would be helpful to know that it's behaving consistently across backends.

@Jiawei-Shao
Copy link
Contributor Author

Hi @kainino0x ,

I haven't started prototyping and testing yet but according to previous investigations the behaviors of clip distances are quite clear and should be same among D3D12, Metal and Vulkan. Do you think now we should have more experiments and prototyping on this feature?

@kainino0x
Copy link
Contributor

IMO for nontrivial changes, at least one prototype and some basic tests should work before we land changes to the spec (and then land the tests).

Generally I'd like the spec to be "evergreen", by which I mean, it should always be a valid target for implementations, and we need implementation experience to be sure of that. We could reevaluate that once we've published a Candidate Recommendation, but right now I think it's necessary.

@kainino0x
Copy link
Contributor

We can discuss at the WG meeting though, maybe people think the investigation already meets the bar needed to land the spec.

@kainino0x kainino0x added wgsl WebGPU Shading Language Issues api WebGPU API labels May 21, 2024
@Jiawei-Shao
Copy link
Contributor Author

Note that in SPIRV-Cross the SPIRV ClipDistance is directly translated into [[clip_distance]] in MSL when it is an vertex output and SV_ClipDistance0 and SV_Clip_Distance1 in HLSL.

@kdashg kdashg merged commit adb07b1 into gpuweb:main May 29, 2024
@dneto0 dneto0 mentioned this pull request May 30, 2024
Closed
1 task
juj added a commit to juj/wasm_webgpu that referenced this pull request Jun 8, 2024
@juj
IDL: Add support for 'clip-distances' feature. gpuweb/gpuweb#4588
81adf3b
@Kangz
Copy link
Contributor

Kangz commented Jun 25, 2024

GPU Web WG 2024-05-29 Atlantic-time
  • JS: Kai had one last comment about whether we needed ??, but this is a pretty straightforward feature to implement on the platform APIs
  • KN: The compressed texture thing is a good example of this: I would like to keep the spec in a good state, and we thought were in good shape with 3D textures but it turned around to bite us. So in the future I would like to be more careful, and get things implemented landed in the CTS before we add things to the spec, so we can keep the spec “Green”
  • KG: Yes, we are supposed to land what we think is “likely” in the working drafts, and you’re not supposed to implement the working drafts. We’re supposed to be focussing on things we need to cut the CR. So we need to focus on actually getting to the CR, not adding new features
  • KR: Just to clarify: working is definitely going towards making CR, lots of PRs from Kai and Brandon
  • KN: So, what does that mean we should do with this PR?
  • KG: Hard to say. In part, I’d like to simply stop adding features to the spec, and stop making our work harder. Alternatively, we should just branch already, and separate the thing we’re going to move to CR from the WD that we’re going to continue to contribute new features to.
  • MM: from an outsider's perspective, CR means nothing, and implementations are what actually matter. if implementations aren't going to implement something, it makes sense to wait to land in the spec. otherwise, landing is good
  • KG: These things we’re considering are too complicated to get right in the first PR. The WD is supposed to be where we land these ideas and iterate on them as we discover problems. The standard is supposed to be the thing that people can expect we’re moving towards implementing.
  • KG: There’s not a single right answer: if this group reaches consensus that we should merge this, then we should merge it. I’m advocating not trying to get this right on the first try. We’re supposed to respond to our attempts to implement them [by adjusting the WD]. But whatever the group’s consensus is on what to do with this PR, that’s what we’ll do.
  • KN: I don’t feel too strongly: If we want to treat the WD as a WD even in this intermediate period, that’s fine with me. We can make sure that nothing we’re positive isn’t ready for CR appears in the CR branch.
  • KG: How does Google feel about merging this PR?
  • KN: Google is okay with merging this PR.
  • KG: I think Mozilla is ready to merge this PR too. Is there more work needed?
  • KN: The spec is ready.
  • Conclusion: merge it
  • (merged)

@kainino0x kainino0x added needs-cts-issue This change requires tests (or would need tests if accepted), but may not have a CTS issue filed yet and removed needs-cts-issue This change requires tests (or would need tests if accepted), but may not have a CTS issue filed yet labels Jul 24, 2024
@cmhhelgeson cmhhelgeson mentioned this pull request Jul 26, 2024
Closed
3 tasks
@EriKWDev EriKWDev mentioned this pull request Sep 8, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@teoxoy teoxoy teoxoy left review comments

@alan-baker alan-baker alan-baker left review comments

@kainino0x kainino0x kainino0x approved these changes

@beaufortfrancois beaufortfrancois beaufortfrancois approved these changes

@Kangz Kangz Awaiting requested review from Kangz

@dneto0 dneto0 Awaiting requested review from dneto0

@kdashg kdashg Awaiting requested review from kdashg

Assignees
No one assigned
Labels
api WebGPU API wgsl WebGPU Shading Language Issues
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

HW Clip Planes support
7 participants
@Jiawei-Shao @beaufortfrancois @Kangz @kainino0x @teoxoy @alan-baker @kdashg