Re: Binary vs Text

> On Nov 6, 2018, at 6:15 PM, Ken Russell <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 , 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
> 
> 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),

That isn’t a problem with the source language being ingested by the browser. It’s a problem with the target language being emitted to the driver. 

If WebGPU said we must accept SPIR-V but AcmeBrowser needed to use a gpu driver that accepted Rust (yuck!!!) but had a buggy parser that could handle more than 5 plus expressions per line, then AcmeBrowser would have the same problem you describe. 

It seems like that’s not what anyone is proposing here. Instead, browsers will have to emit MSL, HLSL, or SPIR-V. That’s regardless of whether the input to the browser is SPIR-V or WHLSL. 

> working around bugs in variable scoping and shadowing, defeating incorrect compiler optimizations, and more.

Again - this is orthogonal to the choice of input language to the browser. If a browser for Mac encountered some awful bugs in MSL (I hope not!) then it would have to do all of those weird things even if the input to the browser was SPIR-V. 

> 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,

And introduce new classes of bugs:

- security bugs resulting from missing bounds checks on the integer variable references. 

- weird bugs in SSA validation, which is no easier than validation of WHLSL’s scoping rules. 

> variables, and scopes. SPIR-V's primitives are lower level than those in a textual shader language,

Not lower level than WHLSL. 

> 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> 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