Re: Binary vs Text

> On Nov 6, 2018, at 4:25 PM, Florian Bösch <pyalot@gmail.com> wrote:
> 
> Framing it as binary vs. text is in my opinion the wrong characterization. It's more about a programming language as text (or whatever format) vs. an intermediate machine independent low level bytecode that's eliminating much of the complexity/optimizations you'd have to apply to a programming language before you can translate it to something the GPU understands (usually such an intermediate low level bytecode format) that it then translates to GPU native code.

Intermediate representations are languages. 

Any language can be used as an intermediate representation. 

Also, SPIR-V and WHLSL will have to use the same optimization pipeline. 

> 
> From WebGL we've learned several things about presenting the driver with text:
> Some intermediate bytecode compilers such as the one shipped with Direct3D are performing badly
> If the text can be passed to the driver directly (as is the case with OpenGL backends for instance), those compilers too may perform badly
> Since every GPU vendor needs to implement a full parser/compiler toolchain, it bloats the driver and introduces interpretation ambiguity where some constructs are not reliably translated to GPU code, and so the emitter of source (the browser) needs to account for a large number of workarounds to homogenize these unfixed issues in drivers.
I keep hearing these problems and believe them to be a historical quirk in GPU languages that need not be repeated. 

Browsers already ingest lots of text formats without performing badly. For example, JS text parsing is consistently better than the alternatives (binary AST ended up being slower to parse and WebAssembly still lags JS in startup time). 

> It'd be desirable to avoid these effects and eliminate a constant source of frustration for graphics programmers. APIs such as Vulkan have recognized this issue and introduced a machine independent low level intermediary bytecode format that is intended to be quick to load onto the GPU and leaves little room for ambiguity of interpretation or complexity of implementation on the drivers part.

I think that the issue we need to recognize is that underspecified languages are bad. 

SPIR-V is underspecified compared to WHLSL at this time. That’s why we are asking to see what the full web spec for SPIR-V looks like. 

-Filip

> 
>> On Tue, Nov 6, 2018 at 7:58 AM 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