I've written a response below, but the summary is that mapping from Vulkan 1.3 with dynamic rendering to D3D11 is easier than targeting the lower-level D3D12. The latter does have some form of dynamic rendering too, but I suspect the authors woud've had to re-think their CPU code much more than what has currently been done. Getting Windows Vista and 7 support is a freebie.
Think about the customer base: the sorts of users who want a high-performance text editor are exactly the kind of people who will run Windows 7 until it's pried from their cold, dead fingers, and who will flood the support forums with complaints if you limit support to operating systems released in the last 15 years. Because of their target market, Zed probably has implicit support requirements which wouldn't apply to e.g. the last first-person shooter.
> Zed probably has implicit support requirements which wouldn't apply to e.g. the last first-person shooter.
This is incongruous given Zed uses modern frameworks (which is why they moved to D3D11 from Vulkan in the first place).
If Zed really wanted to target 'old Windows' then they might have used Win32 and GDI+, not D3D11. In fact they could've stuck to D2D (which was released with Windows 7 and back-ported to Vista), and not used their own rendering at all, since D2D is already a GPU-accelerated text-rendering API, and then used Win32 windowing primitives for everything else.
Zed had already targeted macOS when 10.15 still had over a year of support left https://github.com/zed-industries/zed/commit/b400449a58507cc... and some variant of x86-64 macOS will still be supported through 2028. Neither of these were adding support for really old things, one is current for many years to come and just there hasn't been a reason to break 10.15 support yet so why bother.
Meanwhile Windows 7 is already over 2 years past the end of extra-extended support at the time this new code was written with Windows 7 support still in mind. Which is nice, but a very different scenario.
DX12 isn't just "newer DX11" though, so it really comes down to what makes the most sense for building Zed with.
I've written a response below, but the summary is that mapping from Vulkan 1.3 with dynamic rendering to D3D11 is easier than targeting the lower-level D3D12. The latter does have some form of dynamic rendering too, but I suspect the authors woud've had to re-think their CPU code much more than what has currently been done. Getting Windows Vista and 7 support is a freebie.
If you aren't trying to write a games engine, DX 11 is good enough, and won't be going away any time soon.
Think about the customer base: the sorts of users who want a high-performance text editor are exactly the kind of people who will run Windows 7 until it's pried from their cold, dead fingers, and who will flood the support forums with complaints if you limit support to operating systems released in the last 15 years. Because of their target market, Zed probably has implicit support requirements which wouldn't apply to e.g. the last first-person shooter.
> Zed probably has implicit support requirements which wouldn't apply to e.g. the last first-person shooter.
This is incongruous given Zed uses modern frameworks (which is why they moved to D3D11 from Vulkan in the first place).
If Zed really wanted to target 'old Windows' then they might have used Win32 and GDI+, not D3D11. In fact they could've stuck to D2D (which was released with Windows 7 and back-ported to Vista), and not used their own rendering at all, since D2D is already a GPU-accelerated text-rendering API, and then used Win32 windowing primitives for everything else.
Similarly, the Mac version is for MacOS 10.15 (from 2019) or later, and has an x64 version.
Zed had already targeted macOS when 10.15 still had over a year of support left https://github.com/zed-industries/zed/commit/b400449a58507cc... and some variant of x86-64 macOS will still be supported through 2028. Neither of these were adding support for really old things, one is current for many years to come and just there hasn't been a reason to break 10.15 support yet so why bother.
Meanwhile Windows 7 is already over 2 years past the end of extra-extended support at the time this new code was written with Windows 7 support still in mind. Which is nice, but a very different scenario.
Dx11 is a far more ergonomic API than dx12. Dx12 is what you use when you need maximum control over memory allocation and such