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

Move Detailed Operations section into separate doc #4633

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

toji
Copy link
Member

@toji toji commented May 13, 2024

Taking a stab at what we talked about a few weeks ago, moving this section out to a separate doc so that it doesn't contribute to the appearance of the spec being underdeveloped. This change would move 1 Issue and 15 Editorial Notes out of the main spec.

I was mildly surprised at how many cross references from the spec back to the operations doc were needed, if we move forward with this we may want to look at whether or not some of those definitions should be pulling back into the main spec.

@toji toji requested review from kainino0x and jimblandy May 13, 2024 20:02
Copy link
Contributor

github-actions bot commented May 13, 2024

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


## Transfer ## {#transfer-operations}

<p class="note editorial"><span class=marker>Editorial note:</span> describe the transfers at the high level
Copy link
Contributor

Choose a reason for hiding this comment

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

Since this isn't in the spec anymore I think all of these could be changed back to just normal Issue:s.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

@@ -126,6 +126,23 @@ spec: WGSL; urlPrefix: https://gpuweb.github.io/gpuweb/wgsl/#
text: f16; url: extension-f16
type: abstract-op
text: SizeOf; url: sizeof
spec: WebGPU Detailed Operations; urlPrefix: https://gpuweb.github.io/gpuweb/operations/#
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this would need to be a non-normative document and any references to it only in non-normative parts.

There are many references to it from normative sections, so for each of those we'd either have to move the link into a non-normative Note: or move the target back into this spec. It does look like almost all of them could be non-normative links.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good call. Added text to the top of the operations doc indicating it's non-normative (mimicking language from the correspondence doc). Working on making the references non-normative where appropriate.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've either moved definitions back into the spec (see the new "Render Pass Framebuffer" header) or marked their references as non-normative now with the exception of:

  • clip position
  • clip volume
  • depth clipping
  • output merging

Still mulling on the best way to handle those.

@@ -1963,7 +1980,7 @@ them to WGSL values (`bool`, `i32`, `u32`, `f32`, `f16`).
1. Let |wgslColor| be a WGSL value of type <code>vec4&lt;|T|&gt;</code>, where the 4
components are the RGBA channels of |color|, each [=?=] converted [$to WGSL type$] |T|.

1. Convert |wgslColor| to |format| using the same conversion rules as the [[#output-merging]]
1. Convert |wgslColor| to |format| using the same conversion rules as the [=output merging=]
step, and return the result.
Copy link
Contributor

Choose a reason for hiding this comment

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

This one wouldn't work very well as a non-normative reference.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hrm. The "output merging section" doesn't actually talk about format conversion rules at all at the moment. The only thing it mentions is clamping the depth input to the viewport.

I'll have to figure out a better way to state this that actually points to a relevant resource.

@@ -7597,7 +7614,7 @@ dictionary GPURenderPipelineDescriptor
: <dfn>fragment</dfn>
::
Describes the fragment shader entry point of the [=pipeline=] and its output colors. If
not [=map/exist|provided=], the [[#no-color-output]] mode is enabled.
not [=map/exist|provided=], the [=no color output=] mode is enabled.
Copy link
Contributor

Choose a reason for hiding this comment

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

This one wouldn't work very well as a non-normative reference.

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed

spec/index.bs Outdated
If the builtin is not output from the fragment shader, and {{GPUMultisampleState/alphaToCoverageEnabled}}
is enabled, the [=shader-output mask=] becomes the [=alpha-to-coverage mask=]. Otherwise, it defaults to 0xFFFFFFFF.
For additional details about the various GPU operations performed by WebGPU, see the supplemental
[Detailed Operations](https://gpuweb.github.io/gpuweb/operations/) document.
Copy link
Contributor

Choose a reason for hiding this comment

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

This link would need to be non-normative.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

@kainino0x kainino0x added the api WebGPU API label May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api WebGPU API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants