Re: Binary vs Text

> On Nov 7, 2018, at 12:26 PM, 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,

You mean: the implementor will need some binary format(s) in a part of the compilation pipeline that is not visible to the user. I don’t think this observation is an argument in favor of going binary on the wire. 

> 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. Perhaps, we can define WebSPIR-V in such a way that no work is needed at all? This isn't an option with WebHLSL.

I agree that using SPIR-V creates this advantage for browsers that target SPIR-V. 

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

Translating one language to another is easy if the languages operate at a similar level of abstraction. WebHLSL operates at a similar level of abstraction to SPIR-V. 

> 
>   - parsing and validating SPIR-V may be easier, since the format is very simple (and there isn't any syntactic sugar to care about). 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

Also, that complexity needs to be compared to the complexity of validating the web version of SPIR-V. 

> 
>   - finally, digesting WebSPIR-V would allow WebHLSL to evolve quicker, adopt new programming paradigms, syntax, etc, without waiting for the browsers to be updated.

WebHLSL can evolve as fast as it wants if new versions can compile to old versions. WebHLSL is as much of a compiler target as SPIR-V is. 

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

Received on Wednesday, 7 November 2018 18:55:57 UTC