W3C home > Mailing lists > Public > public-gpu@w3.org > November 2018

Re: Binary vs Text

From: Ken Russell <kbr@google.com>
Date: Tue, 6 Nov 2018 15:15:42 -0800
Message-ID: <CAMYvS2dqTdSe5Q-3qtEf1T4dHcGmqN50e1KMJ=X92UGpZ01r7w@mail.gmail.com>
To: "Myles C. Maxfield" <mmaxfield@apple.com>
Cc: public-gpu <public-gpu@w3.org>
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

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:

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


On Mon, Nov 5, 2018 at 10:58 PM Myles C. Maxfield <mmaxfield@apple.com>

> 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
Received on Tuesday, 6 November 2018 23:16:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:25 UTC