Subject: General Tech | February 7, 2017 - 02:47 AM | Scott Michaud
Tagged: mozilla, firefox, web browser, Rust, llvm
Firefox 52 will be the company’s next Extended Support Release (ESR) branch of their popular web browser. After this release, Mozilla is planning a few changes that will break compatibility, especially if you’re building the browser from source. If you’re an end-user, the major one to look out for is Mozilla disabling NPAPI-based plugins (except Flash) unless you are using Firefox 52 ESR. This change will land in the consumer version of Firefox 52, though. It’s not really clear why they didn’t just wait until Firefox 53, rather than add a soft-kill in Firefox 52 and hard-code it the next version, but that’s their decision. It really does not affect me in the slightest.
The more interesting change, however, is that Mozilla will begin requiring Rust (and LLVM) in an upcoming version. I’ve seen multiple sources claim Firefox 53, Firefox 54, and Firefox 55 as possible targets for this, but, at some point around those versions, critical components of the browser will be written in Rust. As more of the browser is migrated to this language, it should be progressively faster and more secure, as this language is designed to enforce memory safety and task concurrency.
Firefox 52 is expected in March.
Subject: Graphics Cards | January 27, 2017 - 09:19 PM | Scott Michaud
Tagged: microsoft, DirectX, llvm, dxil, spir-v, vulkan
Over the holidays, Microsoft has published the DirectX Shader Compiler onto GitHub. The interesting part about this is that it outputs HLSL into DirectX Intermediate Language (DXIL) bytecode, which can be ingested by GPU drivers and executed on graphics devices. The reason why this is interesting is that DXIL is based on LLVM, which might start to sound familiar if you have been following along with The Khronos Group and their announcements regarding Vulkan, OpenCL, and SPIR-V.
As it turns out, they were on to something, and Microsoft is working on a DirectX analogue of it.
The main advantage of LLVM-based bytecode is that you can eventually support multiple languages (and the libraries of code developed in them). When SPIR-V was announced with Vulkan, the first thing that came to my mind was compiling to it from HLSL, which would be useful for existing engines, as they are typically written in HLSL and transpiled to the target platform when used outside of DirectX (like GLSL for OpenGL). So, in Microsoft’s case, it would make sense that they start there (since they own the thing) but I doubt that is the end goal. The most seductive outcome for game engine developers would be single-source C++, but there is a lot of steps between there and here.
Another advantage, albeit to a lesser extent, is that you might be able to benefit from performance optimizations, both on the LLVM / language side as well as on the driver’s side.
According to their readme, the minimum support will be HLSL Shader Model 6. This is the most recent shading model, and it introduces some interesting instructions, typically for GPGPU applications, that allow multiple GPU threads to interact, like balloting. Ironically, while DirectCompute and C++AMP don’t seem to be too popular, this would nudge DirectX 12 into a somewhat competent GPU compute API.
DXIL support is limited to Windows 10 Build 15007 and later, so you will need to either switch one (or more) workstation(s) to Insider, or wait until it launches with the Creators Update (unless something surprising holds it back).