3 ms·

As a Windows dev... > but we got reports from users that Zed didn't run on their machines due to the Vulkan dependency This single sentence is abstracting a l

As a Windows dev... > but we got reports from users that Zed didn't run on their machines due to the Vulkan dependency This single sentence is abstracting a lot of detail. Vulkan runs on Windows, and quite well. Looking at the bug reports, especially the last one[1]... > Rejected for device extension "VK_KHR_dynamic_rendering" not supported Aha, ambitious devs >:) The dynamic rendering extension is pretty new, released with Vulkan 1.3. I suspect targeting Vulkan 1.1 or 1.2 might've been a little more straightforward than... rewriting everything to target DX11. Large games with custom engines (RDR2, Doom, Doom Eternal) were shipped before this was main-lined into Vulkan. But thinking about it a little more, I suspect switching out the back-end to a dynamic rendering-esque one (which is why D3D11 rather than D3D12) was easier than reverting their Rust code to pre-dynamic rendering Vulkan CPU calls; the Rust code changes are comparatively light and the biggest change is the shader. That being said, it's a bit annoying to manually write render-passes and subpasses, but it's not the worst thing, and more importantly extremely high performance is less critical here, as Zed is rendering text, not shading billions of triangles. The singular shader is also not necessarily the most complex[2]; a lot of it is window-clipping which Windows does for free. > we had two implementations of our GPU shaders: one MSL implementation for macOS, and one WGSL implementation for Vulkan. To use DirectX 11, we had to create a third implementation in HLSL. I wonder why HLSL wasn't adopted from the outset, given roughly 99.999% of shaders—which are mostly shipped with video games, which mostly target Windows—are written in HLSL, and then use dxc to target SPIR-V? HLSL is widely considered the best-specified, most feature-complete, and most documented shader language. I'm writing a Vulkan engine on Windows and Linux, and I only use HLSL. Additionally Vulkan runs on macOS with MoltenVK (and now 'KosmicKrisp'), but I suppose the Zed spirit is 'platform-native and nothing else'. > symbolicating stack traces requires a .pdb file that is too large to ship to users as part of the installer. Perhaps publishing a symbol server[3] is a good idea here, rather than users shipping dump files which may contain personally-identifiable information; users can then use WinDbg or Visual Studio to debug the release-mode Zed at their leisure. [1]: https://github.com/zed-industries/zed/issues/35205 https://github.com/zed-industries/zed/issues/35205 [2]: https://github.com/zed-industries/zed/blob/c995dd2016a3d9f8bd5dfe5d43972bc8de768ca6/crates/gpui/src/platform/windows/shaders.hlsl https://github.com/zed-industries/zed/blob/c995dd2016a3d9f8b... [3]: https://randomascii.wordpress.com/2020/03/14/creating-a-public-symbol-server-easily/ https://randomascii.wordpress.com/2020/03/14/creating-a-publ...

andrewmcwatters 1y ago
Yeah, I maintain a Vulkan backend, and this immediately triggered my internal "what?" alarm. Modern Direct3D is almost indistinguishable from Vulkan, on the other hand. So it shouldn't be difficult for them to add. I also agree with your HLSL comment. It sounds like these guys don’t have much prior graphics or game development experience.
- delta_p_delta_x 1y ago
  I'd been thinking about it, and I added another paragraph above. I get a feeling they've been targeting Vulkan 1.3 with dynamic rendering from the beginning, so porting to D3D12 would be roughly as complex as rewriting to target older Vulkan.
maxbrunsfeld 1y ago
The Zed spirit is definitely to prefer a platform native solution. You're right that we may be able to get rid of our WGSL implementation, and instead use the HLSL one via SPIR-V. But also, at some point we plan to port Zed to run in a web browser, and will likely build on WebGPU, where WGSL is the native shading language. Honestly, we don't change our graphics primitives that frequently, so the cost of having the three implementations going forward isn't that terrible. We definitely would not use MoltenVK on macOS, vs just using Metal directly. Good point that we should publish a symbol server.
- jamienicol 1y ago
  Did you consider using wgpu instead of writing a new dx11 renderer? It has metal, vulkan and dx12 backends so could have been used for a single renderer for macOS windows and Linux. (And webgpu in the future)
- bsder 1y ago
  > But also, at some point we plan to port Zed to run in a web browser, and will likely build on WebGPU, where WGSL is the native shading language. Except that everything has effectively converged to HLSL (via Slang which is effectively HLSL++) and SPIR-V (coming via Shader 7). So, your pipelines, shader language, and IR code would all look mostly the same between Windows and Linux if you threw in with DX12 (which looks much more like Vulkan) rather than DX11. And you'd get the ability to multi-thread through the GPU subsystem via DX12/Vulkan. And, to be fair, we've seen that MoltenVK gets you about 80-90% of native Metal performance on macOS, so you wouldn't have to maintain a Metal backend, anymore. And you'd gain the ability to use all the standard GPU debugging tools from Microsoft, nVidia, and AMD rather than just RenderDoc. You'd abandon this all for some mythical future compatibility with WebGPU--which has deployment counts you can measure with a thimble?

andrewmcwatters 1y ago

Yeah, I maintain a Vulkan backend, and this immediately triggered my internal "what?" alarm. Modern Direct3D is almost indistinguishable from Vulkan, on the other hand. So it shouldn't be difficult for them to add. I also agree with your HLSL comment. It sounds like these guys don’t have much prior graphics or game development experience.

delta_p_delta_x 1y ago
I'd been thinking about it, and I added another paragraph above. I get a feeling they've been targeting Vulkan 1.3 with dynamic rendering from the beginning, so porting to D3D12 would be roughly as complex as rewriting to target older Vulkan.

maxbrunsfeld 1y ago

The Zed spirit is definitely to prefer a platform native solution. You're right that we may be able to get rid of our WGSL implementation, and instead use the HLSL one via SPIR-V. But also, at some point we plan to port Zed to run in a web browser, and will likely build on WebGPU, where WGSL is the native shading language. Honestly, we don't change our graphics primitives that frequently, so the cost of having the three implementations going forward isn't that terrible. We definitely would not use MoltenVK on macOS, vs just using Metal directly. Good point that we should publish a symbol server.

jamienicol 1y ago
Did you consider using wgpu instead of writing a new dx11 renderer? It has metal, vulkan and dx12 backends so could have been used for a single renderer for macOS windows and Linux. (And webgpu in the future)
bsder 1y ago
> But also, at some point we plan to port Zed to run in a web browser, and will likely build on WebGPU, where WGSL is the native shading language. Except that everything has effectively converged to HLSL (via Slang which is effectively HLSL++) and SPIR-V (coming via Shader 7). So, your pipelines, shader language, and IR code would all look mostly the same between Windows and Linux if you threw in with DX12 (which looks much more like Vulkan) rather than DX11. And you'd get the ability to multi-thread through the GPU subsystem via DX12/Vulkan. And, to be fair, we've seen that MoltenVK gets you about 80-90% of native Metal performance on macOS, so you wouldn't have to maintain a Metal backend, anymore. And you'd gain the ability to use all the standard GPU debugging tools from Microsoft, nVidia, and AMD rather than just RenderDoc. You'd abandon this all for some mythical future compatibility with WebGPU--which has deployment counts you can measure with a thimble?