windows: [WIP] A DirectX 11 backend prototype

[JunkuiZhang]

I've recently been working on migrating Zed's implementation on Windows to DirectX 11 and I need your suggestions and advices to decide whether to continue.

Why Migrate to DirectX?

We already have a Vulkan backend implementation, so why go through the effort of migrating to DirectX? Migrating to DirectX brings several benefits, such as:

• Support for transparent backgrounds
• Minimal memory usage
• Using DirectX can help fix issues like NoSupportedDeviceFound encountered with Vulkan. I think DirectX has better compatibility. Even if you don't have a hardware GPU driver, you can still use the software driver provided by Windows.

Why Use DirectX 11 Instead of DirectX 12?

DirectX 12 is complex and challenging. Many things require manual management, including switching the backbuffer after presenting the buffer and handling both resource and hardware synchronization yourself. Furthermore, DirectX 11's performance is not that bad, as demonstrated by games like CS:GO and Dota 2 which use DirectX 11. I think the effort required for DirectX 12 does not justify the marginal performance gains.

Memory Usage

Before this PR, Zed uses about 150MB memory, under this PR, Zed uses around 50MB.

Transparent Background

To implement a transparent background, we need to create a swapchain using CreateSwapchainForComposition. I believe this is quite challenging to achieve with Vulkan.

Release Notes:

• N/A

[mikayla-maki]

Unfortunately, I don't think this is something we're interested in merging as we don't have the capacity to support Windows developers yet. I'd suggest seeing if blade / @kvark is interested in having this as a backend, as supporting DirectX is probably going to be part of our Windows port work one way or another.

[mikayla-maki]

Also, I'd like to also say that it's super cool to see you diving in on this!

[kvark]

I'd like to see only a few backends supported. Previously in the GPU abstractions I worked on, such as gfx we tried to get every single graphics API. It comes with a big maintenance cost and driver headaches. For Blade, the idea is that the primary path is being optimized for: Vulkan on Linux/Windows, and Metal on Apple. And then there is a secondary path for compatibility only - this is OpenGL ES. This compatibility path is ultra portable, since, in addition to targeting Linux and Web, it can be run with Google's ANGLE (e.g. to translate to DX11).
I believe this distinction (between primary vs compatibility path) is working well, and I think we shall keep it.

@JunkuiZhang this is very big and impressive work btw!
I'd like to comment on some of the points

Support for transparent backgrounds

We do support it in Vulkan as of #10973

Minimal memory usage

I love small and quick apps, and I appreciate the drive to perfection here!
There is a room for improvement with Blade on this to reduce the 150mb mark. We can tune the memory allocator, for instance, if anyone is interested. I'm more inclined to get the visual issues and latency right as I get time to contribute (e.g. #13203).

Using DirectX can help fix issues like NoSupportedDeviceFound encountered with Vulkan

That's definitely true. Echoing @apricotbucket28, I think we should make the GLES backend work well, and we can run it on top of ANGLE on Windows.

[JunkuiZhang]

@kvark Thanks for your kind word and reply!

Support for transparent backgrounds

We do support it in Vulkan as of #10973

Implementing a transparent background on Windows is more complex than it seems. On Windows, achieving a transparent background involves three steps:

1. Remove the window's default buffer: This is easily done by specifying the NOREDIRECTIONBITMAP parameter when creating the window.
2. Create a special swap chain: Normally, we use CreateSwapchain to create a swap chain associated with a window, and I guess Vulkan uses a similar API. However, to create a transparent window, we need to use CreateSwapchainForComposition, which is currently only supported by DirectX.
3. Associate the swap chain to the window using DirectComposition or VisualLayer: This is another feature exclusive to DirectX.

Therefore, I think that if we want to support transparent or blurred backgrounds on Windows in the future, migrating to DirectX will eventually be necessary.

[JunkuiZhang]

Also, I'd like to also say that it's super cool to see you diving in on this!

@mikayla-maki Thank you for your response, really happy to hear from Zed team. The HLSL files in this PR are almost copied and pasted from the Metal shaders and Vulkan's WGSL, which are amazing works implmented by the Zed team and @kvark , I just modified some codes to fit HLSL syntax. I appreciate all your hard work. I will continue to try implement a blurred background.

[JunkuiZhang]

I just implemented blurred background on Windows with DirectX and Visual Layer:

Recording.2024-07-04.013322.mp4

[ZeppLu]

I just implemented blurred background on Windows with DirectX and Visual Layer:

Recording.2024-07-04.013322.mp4

The blur looks amazing! How is it implemented, your own shader/code or Windows 11 Mica effect?

[JunkuiZhang]

The blur looks amazing! How is it implemented, your own shader/code or Windows 11 Mica effect?

The Mica effect and Acrylic effect are XAML only features. So I use the visual layer here, this is some traditional blur effect I guess, the only difference compared with Acrylic seems to be just saturation.

[getpool]

Looking forward to updates to support low-end devices, as older devices do not support vulkan.