All, we updated the execution environment <https://github.com/gpuweb/spirv-execution-env/blob/master/execution-env.md> with more details on OOB behavior (in this pull request <https://github.com/gpuweb/spirv-execution-env/pull/3>). Hopefully it addresses your concerns. Cheers, Corentin On Wed, Nov 14, 2018 at 10:12 PM Corentin Wallez <cwallez@google.com> wrote: > After only 10 emails it's already hard to follow what are the separate > concerns and what has already been stated.. Can you please open one issue > per individual concern on https://github.com/gpuweb/spirv-execution-env? > It would help keep each discussion focused on a single concern and get to a > resolution/fix faster. > > On Wed, Nov 14, 2018 at 8:36 PM Filip Pizlo <fpizlo@apple.com> wrote: > >> It’s not great that to figure these things out, one must read multiple >> specs instead of one. >> >> -Filip >> >> On Nov 14, 2018, at 11:29 AM, Dan Sinclair <dsinclair@google.com> wrote: >> >> On Wed, Nov 14, 2018 at 1:52 PM Maciej Stachowiak <mjs@apple.com> wrote: >> >>> Consider OpUndef. The whole purpose of this instruction is to invoke an >>> undefined behavior for the sake of performance (since initializing may be >>> costly when it’s not necessary). Does any shader program containing OpUndef >>> get rejected? Does it trap and halt? Does it return an arbitrary value that >>> is uninitialized and therefore may lead to reading stale data ? Does it >>> initialize to a specific known value (e.g. zero)? >>> >>> >> The env spec states: >> OpUndef is not allowed. >> >> So, the shader would be rejected as invalid. >> >> dan >> >>
Received on Thursday, 22 November 2018 19:47:49 UTC