Coalesce explanations about OOB in execution-env.md #3
Conversation
Previously discussions about robust resource access and out of bounds in SPIRV were scattered across issues and documents, which made it hard to see the full picture.
execution-env.md
Outdated
|
|
||
| ## WebGPU Execution Environment Specification for SPIR-V | ||
| Validating accesses are in bounds at shader module or pipeline creation time isn't possible because it is equivalent to the halting problem. | ||
| Instead WebGPU implementation should make sure out of bounds accesses don't cause accesses outside of the ExecutionContext. |
execution-env.md
Outdated
| ## WebGPU Execution Environment Specification for SPIR-V | ||
| Validating accesses are in bounds at shader module or pipeline creation time isn't possible because it is equivalent to the halting problem. | ||
| Instead WebGPU implementation should make sure out of bounds accesses don't cause accesses outside of the ExecutionContext. | ||
| This will be typically done by instrumenting the generated code, and because of the performance sensitive nature of it, implementation will have a choice in the behavior of each out of bounds access. |
execution-env.md
Outdated
| Validating accesses are in bounds at shader module or pipeline creation time isn't possible because it is equivalent to the halting problem. | ||
| Instead WebGPU implementation should make sure out of bounds accesses don't cause accesses outside of the ExecutionContext. | ||
| This will be typically done by instrumenting the generated code, and because of the performance sensitive nature of it, implementation will have a choice in the behavior of each out of bounds access. | ||
| Similarly to OpenGL's `GL_KHR_robust_buffer` access extension out of bounds accesses produces most produce the following behaviors: |
There was a problem hiding this comment.
I'm not sure what 'accesses produces most produce' is trying to say? 'accesses must produce'? 'accesses may produce'?
execution-env.md
Outdated
| ### Undefined Behaviour | ||
|
|
||
| The SPIR-V specification states that certain actions by a SPIR-V shader result in _undefined_ _behaviour_. A WebGPU implementation is required to be secure. Therefore in the context of WebGPU, a shader which triggers SPIR-V's undefined behaviour may continue to execute in an arbitrary manner except that it may not sense or mutate any state outside its ExecutionContext, and it may not cause or sense I/O outside its ExecutionContext. | ||
|
|
||
| NOTE: One of the possible behaviours of an ill-behaved application is non-termination. The WebGPU specification should say what happens to a runaway application. TBD | ||
|
|
||
| ### Out of bounds | ||
|
|
||
| Operations that are considered as out of bounds in SPIR-V (that's valid for WebGPU) are the following: |
|
PTAL, addressed all comments. Also we should use "rebase and merge" so that fixups are squashed. |
|
Thanks! |
|
|
||
| ## WebGPU Execution Environment Specification for SPIR-V | ||
| Validating accesses are in bounds at shader module or pipeline creation time isn't possible because it is equivalent to the halting problem. |
There was a problem hiding this comment.
I wouldn't say this. I get what you're trying to say, and maybe this is true with some caveats, but it would be easy for someone to take offense. For example, some Ada dialect has statically verified bounds on all accesses, which they achieve through language restrictions that wouldn't be practical for us. However, I don't think that this Ada dialect solves the halting problem.
I would say: "Validating accesses are in bounds at shader module or pipeline creation time is not possible for all valid SPIR-V programs."
There was a problem hiding this comment.
How about "Validating accesses are in bounds at shader module or pipeline creation time is not possible for all valid shader programs without making the programming model too inflexible."? It encodes your comment about the Ada dialect, and explains this isn't specific to SPIR-V.
Previously discussions about robust resource access and out of bounds in
SPIRV were scattered across issues and documents, which made it hard to
see the full picture.