Migrated from https://bugs.webkit.org/show_bug.cgi?id=189360:

At 2018-09-06T17:52:08Z, [email protected] wrote:
There is an observable bug in the interpreter whereby the shallow copy of values only occurred after all arguments to a call had been evaluated.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189883:

At 2018-09-22T10:28:24Z, [email protected] wrote:
WHLSL functions automatically do null checks, but the native functions don't.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189384:

At 2018-09-06T23:35:57Z, [email protected] wrote:
Support compute shaders

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189484:

At 2018-09-10T22:20:51Z, [email protected] wrote:
[WHLSL] Add the test shader type

See 0. Subgroup support in shading languages mostly overlap but SPIR-V has functions without correspondence in other languages. In this article, only mutual functions are inspected. Tables are divided according to feature categories specified in 0 but risks for unified consideration (as SIMD-group in MacOS and quad-group in iOS) of SIMD-group and quad-group in MSL should be further investigated.

Existing Overlap Work

DirectX Shader Compiler which supports SPIR-V backend for HLSL has an overlap work for HLSL to SPIR-V mapping 1 which we can use as a clue for HLSL to GLSL mapping.

Tables

WebGPUSubgroupFeatureBits::BASIC

WebGPUSubgroupFeatureBits::VOTE

WebGPUSubgroupFeatureBits::BALLOT

WebGPUSubgroupFeatureBits::ARITHMETIC

WebGPUSubgroupFeatureBits::QUAD

References

Specify the alignment and memory order of types

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189175:

At 2018-08-30T21:46:42Z, [email protected] wrote:
Currently WHLSL parses the declaration "int[2][3] array” as an array of length 3 of arrays of 2 integers; we need the reverse to match C.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189134:

At 2018-08-30T00:45:38Z, [email protected] wrote:
Implement semantics

Migrated from https://bugs.webkit.org/show_bug.cgi?id=176117:

At 2017-08-30T19:22:24Z, [email protected] wrote:
Patch forthcoming.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189891:

At 2018-09-22T23:31:34Z, [email protected] wrote:
Right now, sincos() and modf() only accept thread pointers.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189387:

At 2018-09-07T00:10:37Z, [email protected] wrote:
float4 foo(...) : SV_TARGET { ... } is sugar for struct R { float4 stuff : SV_TARGET; } R foo(...) { ... }

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189884:

At 2018-09-22T11:03:57Z, [email protected] wrote:
Implement threadgroup memory

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189204:

At 2018-08-31T19:50:57Z, [email protected] wrote:
Implement SPIR-V code generation

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189986:

At 2018-09-26T04:39:51Z, [email protected] wrote:
[WHLSL] Pointers should have automatically-generated equality checks

Migrated from https://bugs.webkit.org/show_bug.cgi?id=190301:

At 2018-10-05T02:07:43Z, [email protected] wrote:
We need to report errors in things, even if they aren't referenced by any functions.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189176:

At 2018-08-30T23:07:53Z, [email protected] wrote:
[WHLSL] Remove useless code in NameResolver

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189596:

At 2018-09-13T18:39:04Z, [email protected] wrote:
These functions are currently unimplemented in Intrinsics.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189378:

At 2018-09-06T22:26:04Z, [email protected] wrote:
Right now we duplicate the file names in 5 places

We should have something to say about the memory model

Migrated from https://bugs.webkit.org/show_bug.cgi?id=190156:

At 2018-10-01T21:16:17Z, [email protected] wrote:
Performance yay!

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189882:

At 2018-09-22T09:07:50Z, [email protected] wrote:
I'm not sure it's necessary after our removal of generics

Migrated from https://bugs.webkit.org/show_bug.cgi?id=190322:

At 2018-10-05T20:19:41Z, [email protected] wrote:
In the standard library, we have many pieces like

void foo(thread int*);
void foo(device int*);
void foo(threadgroup int*);

if you say foo(nullptr), you get a compile error because it doesn't know which address space nullptr prefers.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189226:

At 2018-09-02T05:25:45Z, [email protected] wrote:
Implement multisampled textures

https://github.com/gpuweb/WHLSL/blob/master/Spec/WSL.g4#L87

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189535:

At 2018-09-12T01:54:09Z, [email protected] wrote:
[WHLSL] The standard library should be fully tested

Uniform validation requires knowing at compilation-time the bounds of resource arrays.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189977:

At 2018-09-25T23:20:15Z, [email protected] wrote:
We synthesize things like operator.length() inside CallExpression._resolveByInstantiation(). We should make sure we catch things like

int x = 7;
x.length(123, 456, 789);

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189936:

At 2018-09-24T23:47:46Z, [email protected] wrote:
WHLSL and MSL shader parameter/return types may differ in their layout — the stage_in parameters need to be flattened into a single struct for example — so shader entry points should unpack their parameters into the expected layout and when they exit they should repack into this format.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189751:

At 2018-09-19T17:07:39Z, [email protected] wrote:
Currently the interpreter allows many attribute parameters, but these should be flattened down into a single struct.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189988:

At 2018-09-26T05:03:18Z, [email protected] wrote:
The dynamic creation of operator==() in Checker causes later checks to succeed or fail. For example, if you cause Checker to generate native bool operator==(int* thread,int* thread) and native bool operator==(int* thread* thread,int* thread* thread), later calls with (nullptr, nullptr) will fail because of an ambiguous overload.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189225:

At 2018-09-02T05:01:25Z, [email protected] wrote:
Implement snorm and unorm texture types

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189982:

At 2018-09-26T01:29:09Z, [email protected] wrote:
All other primitive PODs are supported. See StageInOutSemantics.isAcceptableType.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=190029:

At 2018-09-27T05:30:39Z, [email protected] wrote:
There are no cast operators that allow you to cast a vector (or matrix, for that matter) element-wise. For example:

operator int4(uint4 v)
{
return int4(int(v.x), int(v.y), int(v.z), int(v.w));
}

Metal supports these; I think they would be a useful utility to add to the standard library.

WHLSL’s standard library doesn’t include the double type so it doesn’t make sense to include support for them. On the other hand, we should support syntax for half-precision literals.

See https://github.com/gpuweb/WHLSL/blob/873446a562ee4e6ab7faad391f8a0aa6fd3c9870/Spec/WSL.g4#L22

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189955:

At 2018-09-25T18:09:22Z, [email protected] wrote:
There is no support for the new semantic syntax introduced in https://bugs.webkit.org/show_bug.cgi?id=189134.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189131:

At 2018-08-30T00:04:59Z, [email protected] wrote:
We don't need it any more.

During the F2F last week, Philip raised the issue of how to bound the
variability of an undef value. The troublesome scenario is:

    int i = some_undef_value();
    a[i];  // How to do the bounds check on this?

A naive translation including the bounds-check is:

    int i = some_undef_value();
    if (i < 0 || i >= a_bound) { return fail; }
    a[i];

But each use of an undef value can see a different concrete value, so
upon lowering to the machine and executing the code you could get the
following (uses of i mapping down to 12, 2, and 900 respectively):

    int i = undef;
    if (12 < 0 || 2 >= a_bound) { return fail; }
    a[900]; // Out of bounds!  You have been pown'd.

This is a good problem to solve.

The same problem occurs in digitial circuit design where a circuit block
needs to capture a digital signal from an asyncrhonous input. You
want all uses within your block to use a consistent value (for a given
clock cycle). The "undef" behaviour is analogous to sampling that
asynchronous signal at each use within your block, which leads to
inconsistent values due to differing signal propagation delays to reach
those uses. The standard solution is to sample the asynchronous input
exactly once (with one register in the receiving clock domain), and
then distribute the output of that register to all intended uses within
your block.

(I'm skipping over the metastability management aspect to achieve a
target MTBF. That's not relevant here.)

How does that translate back to the compiler-for-an-ISA domain?
The "undef" behaviour is supposed to give the compiler stack the
freedom to reuse registers for different program (SSA) values without
having to clear the register first or save/spill the register when no
longer needed. The capture behaviour requires the whole compiler stack
to preserve the captured value either within a register or by spilling,
whatever is appropriate.

So, to safely do the bounds check on the array index, you have to
capture the index and use the same captured value for both the bounds
check and the access. In our example, the compiler has to do something
like:

    int i = some_undef_value();
    int i_as_index = CAPTURE(i);  // A new compiler primitive.
    if (i_as_index < 0 || i_as_index >= a_bound) { return fail; }
    a[i_as_index];

The semantics of CAPTURE(x) is:

• if x is undef, then result is some value for typeof(x). The result
  value is not an undef value. That is, all uses of the result will
  see the same value. In concrete terms for common architectures, the
  value is preserved in a register or spilled as needed.

• if x is not an undef, then the result is x.

Each implementation can have its own particular implementation of the CAPTURE
primitive. For example, a crude one could be to map each instance of CAPTURE
to its own variable and executing CAPTURE(X) does a volatile store to the
variable, and uses of the value are volatile loads.

References

[1] "Synchronization in Digital Logic Circuits" (tutorial) Ryan Donohue.
https://web.stanford.edu/class/ee183/handouts/synchronization_pres.pdf

[2] Understanding Metastability in FPGAs (Intel Whitepaper).
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/wp/wp-01082-quartus-ii-metastability.pdf

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189866:

At 2018-09-21T23:42:38Z, [email protected] wrote:
Implement specialization constants

Migrated from https://bugs.webkit.org/show_bug.cgi?id=190172:

At 2018-10-01T22:37:31Z, [email protected] wrote:
It's only valid in fragment shaders, and it has the same semantics as trap (except for no output-merger step later)

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189795:

At 2018-09-20T17:48:01Z, [email protected] wrote:
Currently the sampler and texture types and functions are unimplemented. However, there should be a 1:1 mapping with WHLSL/MSL functions so this shouldn’t take too long.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=190415:

At 2018-10-09T22:23:29Z, [email protected] wrote:
SV_Position isn't allowed as an input to the fragment shader, so you can't naively use the same struct and pass it to both

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189290:

At 2018-09-05T00:32:16Z, [email protected] wrote:
Ternary expressions can be used as l-values:

(someCondition ? a : b) = 42;

It should be possible to take the address of any l-value, however the following doesn’t work:

int a = 42;
int b = 43;
thread int* c = (someCondition ? a : b);

We should either disallow taking the address of a ternary expression, improve the current error message “Bad address space: undefined”, or support this.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=175925:

At 2017-08-24T04:42:40Z, [email protected] wrote:
Patch forthcoming.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189210:

At 2018-08-31T21:20:18Z, [email protected] wrote:
...

Migrated from https://bugs.webkit.org/show_bug.cgi?id=190414:

At 2018-10-09T22:21:41Z, [email protected] wrote:
I wish I could use my keyboard less

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189202:

At 2018-08-31T19:49:31Z, [email protected] wrote:
Prepare the compiler for presentation

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189755:

At 2018-09-19T17:22:16Z, [email protected] wrote:
See EnumType.populateDefaultValue. Consider the enum type

enum A { B = 1, C = 2 }

Currently an A value will be initialized with zero, which isn’t a valid value of the enum. We need to specify this behavior, update the interpreter, and update the compiler.

Metal Shading Language

Metal Shading Language has "Function Constants," (Section 4.10 of the Metal Shading Language 2.1 spec) where you can say something like

constant int a [[function_constant(0)]];

and then there's a two-phase preparation of the shader:

1. Compile the source of the shader by calling MTLDevice.makeLibrary(options:) where you specify the preprocessor macros
2. Specialize the shader by specifying MTLLibrary.makeFunction(constantValues:) where you specify the function constants

GLSL

Similarly, GLSL (and SPIR-V) have "Specialization Constants," (Section 7.2.1 of the OpenGL 4.6 Core spec, and section 4.11 of the GLSL 4.6 spec) where you can say something like

layout (constant_id = 0) const int a = 42;

and then there's a three-phase preparation of the shader:

1. Specify preprocessor macros by manually generating strings of the form "#define foo 5" and injecting them into the GLSL source string at the right place
2. glShaderSource() which presumably does some compilation
3. glSpecializeShader()

GLSL (but not SPIR-V?) also has a concept of subroutines (Section 7.10 of the OpenGL 4.6 Core spec, and section 6.1.2 of the GLSL 4.6 spec), which are just like specialization constants, except for functions. You can say

subroutine float MySignature(float a, float b);
subroutine(MySignature) float foo(float a, float b) { ... }
subroutine(MySignature) float bar(float a, float b) { ... }
subroutine uniform MySignature myUniformName;
... 
float r = myUniformName(3.3, 4.4);

and the OpenGL API hooks up one of foo()/bar to myUniformName. Notably, this happens after compilation, and the value for myUniformName could change each frame / draw call.

HLSL

AFAICT, HLSL doesn't have anything like function constants, specialization constants, or subroutines, but instead has preprocessor macros. You can specify these as arguments to D3DPreprocess().

These constant values lead to better performance than regular constants because they can cause dead code to be removed before the shader ever hits the GPU. This is important for ubershaders, where most of the code will end up being removed.

WHLSL does not include a preprocessor because of the additional complexity it brings. Similarly, on the last WebGPU call where we discussed shading languages, we agreed to remove the ability for user-defined structs/functions to accept type arguments.

The big game engines (Unity, Unreal, etc.) often don't have a single shader to run; instead, they often have families of related shaders. For example, an engine's shader might describe a forward-rendering algorithm, but leave the BRDF and lighting model up to the specific app linking with it. Generics, specialization constants, and preprocessor macros are all ways of making this easier.

Given that HLSL has been successful without specialization constants, perhaps they aren't necessary. On the other hand, WHLSL doesn't have the mechanism that people usually use to specialize HLSL shaders (preprocessor macros). GLSL has both specialization constants and subroutines, but GLSL ES has removed both of those features, so perhaps this entire problem isn't very important. We should figure out what to do here.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189326:

At 2018-09-05T23:17:52Z, [email protected] wrote:
In order to be consistent with C, the arguments of function calls should be evaluated right-to-left. C doesn’t define an evaluation order for operators (like +) but because we treat them as “native functions” we should strictly evaluate them right-to-left.

Migrated from https://bugs.webkit.org/show_bug.cgi?id=189138:

At 2018-08-30T01:29:42Z, [email protected] wrote:
The whole point is they're supposed to match.