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

Discussing this is one of the reasons we’d like to see more details about what Web-SPIR-V would actually look like. We don’t know what kind of transformations a Web-SPIR-V-to-Vulkan-SPIR-V compiler would actually have to perform.

Things like plumbing bounds around with other objects would require rewriting functions and variables and operations on those variables. It would require generating new SSA IDs or possibly regenerating / reassigning them. It would require listing new struct types that weren’t present in the original program.

Because the extent of the differences between Web-SPIR-V and Vulkan-SPIR-V are unknown, it’s unclear the extent of the modification such a compiler would have to perform. I’d like to see what a real compiler would actually have to do, rather than making conjectures.

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

Received on Wednesday, 7 November 2018 21:45:36 UTC