dan sinclair
dan sinclair
When a type is not found for `getResources` we return a default type. Need to fill out the specification of how those default types are setup.
When the `filterable`/`unfilterable`, `filtering`/`non-filtering` work is complete we need to define how the type compatibility with those attributes works in the bindless proposal.
The texture parameters are currently `filterable`, `unfilterable` and `unknown`. They'd be closer to the API spec if they were `float`, `unfilterable_float` and `unknown` (with a future `depth` possibly).
When investigating a failure on M3 macs for Chrome CTS (https://crbug.com/449576833) it looks like the CTS for vertex offsets is passing in non-multiple of 4 values for the offsets (https://github.com/gpuweb/cts/blob/main/src/webgpu/api/operation/vertex_state/correctness.spec.ts#L709)....
Umbrella tracking issue for the explicit layout parameters proposal. Open issues will be filled as sub-bugs.
Can we relax this rule? > If no filterable parameters are provided, then they must be traceable back to static > (non-bindless) bindings, and, as today, the "auto" layout algorithm...
Does the language need the token `unknown`? Just like there is no `void` type, not listing a template parameter will imply a default to the `unknown` enumeration value, but we...
Need to verify that the conversions satisfy the Liskov substitution principles. * `texture_*d` -> `texture_*d` * `sampler` -> `sampler`
In the GLSL 4.60 spec it states: > Lines separated by the line-continuation character preceding a new-line are concatenated > together before either comment processing or preprocessing. The `#version` is...