Re: Binary vs Text

> On Nov 7, 2018, at 2:15 PM, Kai Ninomiya <kainino@google.com> wrote:
> 
> > OpLifetimeStart and OpLifetimeEnd are instructions in the SPIR-V language, which presumably means that lifetimes are not clearly expressed with those instructions. Even with the addition of those instructions, they can’t be trusted because they have to be validated, which means they could lie.
> 
> According to your links, OpLifetimeStart/OpLifetimeEnd are only valid with Kernel capability (i.e. OpenCL). I would guess this is related to physical pointers.
> 
> > Things like plumbing bounds around with other objects would require rewriting functions and variables and operations on those variables. It would require generating new SSA IDs or possibly regenerating / reassigning them
> 
> Generating and reassigning SSA IDs is extremely simple compared with non-SSA IDs. This is why SSA is used in modern compilers to begin with.
> 
> > The evidence from WebAssembly vs JavaScript suggests this probably won’t be true (if by “easier” you mean either “faster” or “simpler to code correctly”).
> 
> It sounds like you are claiming that the JavaScript parser/code generator is not more complex than the WASM parser/code generator. Is this correct? Can you provide evidence for this claim?

I'm more specifically claiming that it is not significantly harder to code correctly; not necessarily that it’s not more complex. But to address this point. In WebKit, I think it’s fair to say our JS code generator is more complex. There are two main reasons:

(1) Our JS has more execution tiers than our WASM. (This is a flaw in WASM and we plan to add more tiered compilation.)
(2) Performant JavaScript execution requires runtime type profiling, specialization based on runtime information, polymorphic inline caches, and similar tricks required to make a dynamic language go fast.

Neither of these issues would apply in the shader context:

(1) Tiered compilation does not seem appropriate for shaders (but if it did, there’s no reason WHLSL wouldn’t need more or fewer tiers than WebSPIR-V).
(2) WHLSL is not a dynamic language calling for the kinds of performance tricks that JavaScript does.

Setting aside than these two issues, my sense is that the complexity is otherwise similar. Perhaps Filip (who is one of the principal architects of our JavaScript engine) could give more insight. This is very subjective though.


A more apples-to-apples comparison would be WASM vs asm.js, in a browser that has a specialized compiler for asm.js. Asm.js has extra validation requirements since it is specified as a subset of a much more general language. This is a factor that would not apply to WHLSL. But other than that, its execution model is very similar to WASM, so a specialized compiler for it doesn’t have to  care about potential dynamism. Regrettably WebKit does not have a specialization. However, Mozilla/Gecko/SpiderMonkey does. My sense is that the codegen complexity is very similar.

Regards,
Maciej

> 
> On Wed, Nov 7, 2018 at 2:11 PM Myles C. Maxfield <mmaxfield@apple.com <mailto:mmaxfield@apple.com>> wrote:
>> On Nov 6, 2018, at 3:55 PM, Jeff Gilbert <jgilbert@mozilla.com <mailto:jgilbert@mozilla.com>> wrote:
>> 
>> I don't think it's necessarily helpful to think of this discussion as
>> predominately binary vs text.
>> 
>> I think there is a lot of value in a constrained, targeted ingestion
>> format, *and separately* I think SPIR-V is a natural choice for this
>> ingestion format.
>> 
>> SPIR-V's core format is very, very easy to parse,
> 
> 
> SPIR-V is a sequence of 32-bit words, so you’re right that it’s easy to read a sequence of 32-bit words.
> 
> However, a Web browser’s job is to understand any possible sequence of inputs. What should a browser do when it encounters two OpEntryPoint <https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#OpEntryPoint> instructions that happen to have the same name but different execution models? What happens when an ArrayStride <https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#Decoration> decoration is set to 17 bytes? What happens when both SpecId and BuiltIn decorations are applied to the same value <https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#_a_id_shadervalidation_a_validation_rules_for_shader_a_href_capability_capabilities_a>? SPIR-V today is clearly not a dream for ingestion. It is more difficult for a browser to understand a SPIR-V program than a WHLSL program.
> 
>> and lends itself
>> well to simple but robust parsing. Lifetimes are clearly expressed,
>> instruction invocations are very explicit, and ecosystem support is
>> already good. It's a dream format for ingestion.
>> 
>> Binning it with other (particularly older) binary formats is just
>> inaccurate. Doing the initial parse gives you the structures
>> (functions, types, bindings) you want pretty immediately. By
>> construction, most unsafe constructs are impossible or trivially
>> validatable. (SSA, instruction requirements, unsafe types, pointers)
>> 
>> For what it's worth, text formats are technically binary formats
>> with a charset. I would rather consume a constrained,
>> rigidly-structured (SSA-like? s-expressions?) text-based assembly
>> than some binary formats I've worked with. (DER, ugh!)
>> 
>> Disentangling our ingestion format from the pressures of both
>> redundancies and elisions that are desirable in directly-authored
>> languages, simplifies things and actually prevents ambiguity. It
>> immediately frees the authoring language to change and evolve at a
>> faster rate, and tolerates more experimentation.
>> 
>> I would rather solve the compilation tool distribution use-case
>> without sacrificing simplicity and robustness in ingestion. A
>> authoring-to-ingestion language compiler in a JS library would let us
>> trivially share everything above the web-IR->host-IR translation,
>> including optimization passes.
>> On Tue, Nov 6, 2018 at 3:16 PM Ken Russell <kbr@google.com <mailto:kbr@google.com>> wrote:
>>> 
>>> Hi Myles,
>>> 
>>> Our viewpoint is based on the experience of using GLSL as WebGL's input language, and dealing with hundreds of bugs associated with parsing, validating, and passing a textual shading language through to underlying drivers.
>>> 
>>> Kai wrote this up at the beginning of the year in this Github issue: https://github.com/gpuweb/gpuweb/issues/44 <https://github.com/gpuweb/gpuweb/issues/44> , and there is a detailed bug list (which is still only a sampling of the associated bugs we fixed over the years) in this spreadsheet:
>>> https://docs.google.com/spreadsheets/d/1bjfZJcvGPI4M6Df5HC8BPQXbl847RpfsFKw6SI6_T30/edit#gid=0 <https://docs.google.com/spreadsheets/d/1bjfZJcvGPI4M6Df5HC8BPQXbl847RpfsFKw6SI6_T30/edit#gid=0>
>>> 
>>> Unlike what I said on the call, the main issues aren't really around the parsing of the input language or string handling. Both the preprocessor's and compiler's parsers in ANGLE's shader translator are autogenerated from grammars. Of more concern were situations where we had to semi-arbitrarily restrict the source language so that we wouldn't pass shaders through to the graphics driver which would crash its own shader compiler. Examples included having to restrict the "complexity" or "depth" of expression trees to avoid stack overflows in some drivers (this was added as an implementation-specific security workaround rather than to the spec), working around bugs in variable scoping and shadowing, defeating incorrect compiler optimizations, and more. Please take the time to read Kai's writeup and go through the spreadsheet.
>>> 
>>> The question will come up: would using a lower-level representation like SPIR-V for WebGPU's shaders really address these problems? I think it would. SPIR-V uses  SSA form and simple numbers for variables, which will eliminate entire classes of bugs in mishandling of language-level identifiers, variables, and scopes. SPIR-V's primitives are lower level than those in a textual shader language, and if it turns out restrictions on shaders are still needed in WebGPU's environment spec in order to work around driver bugs, they'll be easier to define more precisely against SPIR-V than source text. Using SPIR-V as WebGPU's shader ingestion format would bring other advantages, including that it's based on years of experience developing a portable binary shader representation, and has been designed in conjunction with GPU vendors across the industry.
>>> 
>>> On the conference call I didn't mean to over-generalize the topic to "binary formats vs. text formats in the browser", so apologies if I misspoke.
>>> 
>>> -Ken
>>> 
>>> 
>>> 
>>> On Mon, Nov 5, 2018 at 10:58 PM Myles C. Maxfield <mmaxfield@apple.com <mailto:mmaxfield@apple.com>> wrote:
>>>> 
>>>> Hi!
>>>> 
>>>> When we were discussing WebGPU today, the issue of binary vs text was raised. We are confused at the viewpoint that binary languages on the Web are inherently safer and more portable than text ones. All of our browsers accept HTML, CSS, JavaScript, binary image formats, binary font files, GLSL, and WebAssembly, and so we don’t understand how our teams came to opposite conclusions given similar circumstances.
>>>> 
>>>> Can you describe the reasons for this viewpoint (as specifically as possible, preferably)? We’d like to better understand the reasoning.
>>>> 
>>>> Thanks,
>>>> Myles
>>