Conversation
|
Please take a look, thanks |
|
That's a lot of reviewers you added. Can you try to limit them a bit, maybe one for the API spec and one for the WGSL spec? |
kainino0x
left a comment
There was a problem hiding this comment.
(reviewed API spec only)
alan-baker
left a comment
There was a problem hiding this comment.
WGSL looks good overall. Mostly minor comments.
| * the 32-bit signed integer value `1i`, | ||
| * the 32-bit unsigned integer value `1u`, | ||
| * the 32-bit floating point value `1.0f`, | ||
| * the 16-bit floating point value `1.0h` if `f16` extension is enabled, |
There was a problem hiding this comment.
If f16 is not enabled, what is the value of 1.0h? That is, is the h suffix valid with the extension enabled?
I would suggest it should be a shader-creation error if the h suffix is used without the extension enabled.
There was a problem hiding this comment.
It is now explicitly stated in the Literals section.
| <table class='data'> | ||
| <thead> | ||
| <tr><td>Overload<td>Description | ||
| <tr><td>Parameterization<td>Overload<td>Description |
There was a problem hiding this comment.
I'm not a huge fan of the asymmetry here between pack and unpack built-in functions. I'd suggest either removing the f16 versions of packing or rename all the functions similarly to MSL, e.g.:
pack4x8snormf16
pack4x8snormf32
unpack4x8snormf16
unpack4x8snormf32
There was a problem hiding this comment.
Remove the f16 version of packing.
alan-baker
left a comment
There was a problem hiding this comment.
Thanks for the changes!
dneto0
left a comment
There was a problem hiding this comment.
This looks great!
I pointed out a couple of grammar details that we can fix before or after landing.
| |T| is i32, u32, or f32 | ||
| <td class="nowrap">bitcast<vec4<f16>>(|e|): vec4<f16> | ||
| <td>Reinterpretation of bits as vec4<f16>.<br> | ||
| The result is the reinterpretation of the 64 bits in |e| as a vec4<f16> value, following the internal layout rules. |
There was a problem hiding this comment.
This is a really nice way to say it: "following the internal layout rules".
There was a problem hiding this comment.
To be clear, I'm not asking for a change. But I think after landing there may be a way to simplify this section by referencing the layout rules for the whole section.
WGSL meeting minutes 2022-04-05
|
|
@tidoust |
Sorry about that. When this happens, it means that the IPR bot crashed when it ran. That does not happen often but it does happen once in a while. Unfortunately, as far as I know, there is no easy way to re-run the bot on the PR when that happens, except by re-creating the PR. I confirm that the IPR bot would have reported a green flag here, and suggest that spec editors merge the PR as-is (they should have the power to do so from a GitHub permissions perspective). |
Thanks! |
WGSL meeting minutes 2022-04-12
|
|
Shall this PR close issue #658? |
* FP16 Extension spec: WIP * Add ID for extension list section. * Fix typo * Fix typo * Changes for WebGPU spec * Fix typo * Fix typo * Fix typo * Update accroding to comments * F16 literals require f16 extension * Remove packing function for f16 * Fix grammar
* FP16 Extension spec: WIP * Add ID for extension list section. * Fix typo * Fix typo * Changes for WebGPU spec * Fix typo * Fix typo * Fix typo * Update accroding to comments * F16 literals require f16 extension * Remove packing function for f16 * Fix grammar
FP16 extension against the whole spec, merging the proposed changes into WebGPU and WGSL spec.
The related issue is #2512.
The FP16 extension document (PR #2647) is intend to be aligned with this PR.
Preview | Diff