Re: Binary vs Text

> On Nov 7, 2018, at 9:26 AM, Dzmitry Malyshau <dmalyshau@mozilla.com> wrote:
> 
> 
> On 11/7/18 10:29 AM, Filip Pizlo wrote:
>> 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.
> 
> 
> I'd like to expand on that (in a similar direction that Florian mentioned, but expressed differently). It appears that all modern driver-digested shading languages are binary:
> 
>   - on Dx12 you compile HLSL -> DXBC/DXIL and that is fed to the driver
> 
>   - on Apple you compile MSL -> MTL library, which is what Metal gets the function pointers from
> 
>   - on Vulkan you provide SPIR-V generated from anything you like
> 
> 
> So in the end we'd need a binary format, and it seems to me that going from WebSPIR-V  -> DXBC/DXIL/MTL/VkSPIR-V is easier than going from WebHLSL. In particular:
> 
>   - WebSPIR-V to VkSPIR-V conversion may mostly involve a pass-through copying of chunks, with occasional inserting of bounds checks and other safe guards.

This is much more dangerous than parsing, processing, and generating new output. Any passthrough in the system creates a dangerous opportunity for security bugs.

> Perhaps, we can define WebSPIR-V in such a way that no work is needed at all?

Probably not. There’s constructs that need bounds checks added (which the back end might sometimes elide). Google’s draft document on safe ingestion of WebSPIR-V includes rewrites. An alternative is to require WebSPIR-V to come with the required explicit bounds checks, but then validation is much harder and existing tools that emit SPIR-V won’t work.

> This isn't an option with WebHLSL.

Also not an option for WebSPIR-V on top of Metal or Dx12. If there was an opportunity to have a neat shortcut for a Vulkan back end only, that has some value, but helping only one of our target back ends has to be balanced against taking away source viewing and runtime compilation for all authors targeting all back ends.

That said, I think passthrough is impossible and would likely be  a bad idea even if it was possible.

> 
>   - there is prior art for SPIR-V to anything (SPIRV-Cross) as well as incentive to join forces with Khronos VkPortability in writing and maintaining one. It doesn't have to be SPIRV-Cross in particular, the point is that we'd have the same goals here: we can share the resource binding layouts of produced shaders, test suites, ideas, etc.
> 
>   - parsing and validating SPIR-V may be easier, since the format is very simple (and there isn't any syntactic sugar to care about).

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”).

> Since Apple is dedicated to writing WebHLSL converters and validation, I think we'll soon have the evidence to see how the code complexity and performance fares against one based on WebSPIR-V

We have preliminary results showing that compiling WHLSL to Metal results in shaders that are fast to run, but we don’t yet have a compiler that’s good enough to test how compile speed affects this.

> 
>   - finally, digesting WebSPIR-V would allow WebHLSL to evolve quicker, adopt new programming paradigms, syntax, etc, without waiting for the browsers to be updated.
> 
> Note: unfortunately, there isn't currently a way to generate MTL library without going through MSL. Is this something we can potentially ask Apple for in future updates?

If we concluded this was essential to making WebGPU work well on macOS and iOS, we’d talk to the Metal team about it. Right now there’s no officially blessed input form the then MSL.

Regards,
Maciej'

Received on Wednesday, 7 November 2018 21:22:40 UTC