With the caveat there are some issues around UB (IIRC) that will need to be addressed in SPIR-V to make a Web-SPIR-V. If they can’t be addressed then we might need something new.
-
-
1 reply 0 retweets 0 likes
-
Replying to @jfbastien @Gok and
jgilbert and kvark on our side have thought about this a lot more deeply than I have and I’ll defer to them :)
1 reply 0 retweets 0 likes -
Replying to @pcwalton @jfbastien and
To expand - the point is that SPIR-V doesn’t really have a spec. It has words on pages that say things, but specs have pseudo algorithms that tell you unambiguously what the possible executions look like, and SPIR-V lacks that particular detail.
3 replies 0 retweets 5 likes -
Why not clarify the environment for the web then (exactly what Google is doing)? Similarly Metal appears underspecified too (at least from public docs), yet it will be used as a backend
1 reply 0 retweets 0 likes -
Metal Shading Language is not being proposed as a web standard
1 reply 0 retweets 0 likes -
Of course, I'm simply pointing out that UB in implementations should also receive some level of attention and ideally be clarified – just like Google is doing with SPIR-V
1 reply 0 retweets 0 likes -
It certainly should remove UB. However, PNaCl did the same removal of UB, with a handwavy spec, and this helped it ~zero in how it was perceived. I'm asking why SPIR-V is any different, and what can be learned from WebAssembly's success.
1 reply 0 retweets 0 likes -
Replying to @jfbastien @grovesNL and
I think a difference is that a design goal of SPIR-V was for it to be a distribution format for shaders for native apps, while LLVM IR was designed as an internal compiler IR.
1 reply 0 retweets 0 likes -
That’s unrelated to PNaCl though, since it had its own IR (sure, derived from llvm, but different in substantial ways).
1 reply 0 retweets 0 likes
Well, “derived from LLVM” is the relevant part. If it had its own IR, and used the Web APIs over Pepper, it would be a different story. (It’d be wasm, basically) :) TBH, I think Pepper was the larger concern.
-
-
Agree WebAssembly IR is better, yet: "a design goal of SPIR-V was for it to be a distribution format for shaders for native apps, while PNaCl IR was designed to be a distribution format for static language applications" is how I'd rephrase your statement. Both sound fine!
1 reply 0 retweets 0 likes -
Replying to @jfbastien @pcwalton and
I agree that Pepper was a large concern, but that's not all the discussion revolved around. I'm still questioning why SPIR-V is fine given what we've learned from asm.js, PNaCl and WebAssembly. I'm not saying SPIR-V is the wrong choice, I'm asking what it's learned from history.
0 replies 0 retweets 0 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.