> 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.
Entirely unrelated, but the sections, toolbars, and controls in that RenderDoc app are so cleanly separated compared to modern dev tools. I wish more apps still looked like this.
I’m sure this is a dumb question, but why does a code editor need to render on the GPU like a video game? Is it just for niceties like smooth scrolling?
The zed blog has an early post[0] talking some about their decision. Mainly just decrying their experience of impossible-to-meet timing deadlines for something as basic as 60fps on electron.
It doesnt really do a tech breakdown of why it’d be impossible CPU side, but mentions a couple of things about their design process for it.
For people that use scoop and want to try Zed there's a precompiled binary they can install using scoop install zed.
I tried it and the experience (mainly visually, fonts colours etc) wasn't very good so I can understand why the Zed developers are reluctant to formally release windows binaries.
9 comments
[ 5.9 ms ] story [ 46.3 ms ] thread> 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
[2]: https://github.com/zed-industries/zed/blob/c995dd2016a3d9f8b...
[3]: https://randomascii.wordpress.com/2020/03/14/creating-a-publ...
Zedless: Zed fork focused on privacy and being local-first - https://news.ycombinator.com/item?id=44964916
Sequoia backs Zed - https://news.ycombinator.com/item?id=44961172
It doesnt really do a tech breakdown of why it’d be impossible CPU side, but mentions a couple of things about their design process for it.
[0]: https://zed.dev/blog/videogame
I tried it and the experience (mainly visually, fonts colours etc) wasn't very good so I can understand why the Zed developers are reluctant to formally release windows binaries.