[webkit-reviews] review granted: [Bug 198644] [WHLSL] Hook up compute : [Attachment 371612] Patch
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Jun 10 01:01:46 PDT 2019
Saam Barati <sbarati at apple.com> has granted Myles C. Maxfield
<mmaxfield at apple.com>'s request for review:
Bug 198644: [WHLSL] Hook up compute
https://bugs.webkit.org/show_bug.cgi?id=198644
Attachment 371612: Patch
https://bugs.webkit.org/attachment.cgi?id=371612&action=review
--- Comment #6 from Saam Barati <sbarati at apple.com> ---
Comment on attachment 371612
--> https://bugs.webkit.org/attachment.cgi?id=371612
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=371612&action=review
r=me
> Source/WebCore/ChangeLog:18
> + doesn't always match WHLSL's (and HLSL's type). For example, in
WHLSL and HLSL, SV_DispatchThreadID variables have to be a float3, but
in Metal, they are a uint3.
Why do they have to be float3 in WHLSL?
> Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLEntryPointScaffolding.cpp:195
> + ASSERT(builtInSemantic.variable() ==
AST::BuiltInSemantic::Variable::SVGroupThreadID);
Nit: I like to write this out as a case, and omit the “default”. Then, when
anyone adds a new enum value, this becomes a compile error
> Source/WebCore/Modules/webgpu/WHLSL/WHLSLComputeDimensions.cpp:54
> + Visitor::visit(functionDeclaration);
Why?
> Source/WebCore/Modules/webgpu/WHLSL/WHLSLStandardLibrary.txt:596
> +native float operator.w(float4);/*
And this too?
> LayoutTests/webgpu/whlsl-compute.html:9
> +[numthreads(2, 1, 1)]
Out of curiosity, why do we have thread IDs in three dimensions? Is this just a
useful format for a lot of shaders to avoid doing some math or something?
> LayoutTests/webgpu/whlsl-compute.html:64
> + shouldBe("resultsFloat32Array[0]", "2");
👌🏼
More information about the webkit-reviews
mailing list