Is webgpu a good standard at this point? I am learning vulkan atm and 1.3 is significantly different to the previous APIs, and apparently webgpu is closer in behavior to 1.0. I am by no means an authority on the topic, I just see a lack of interest in targeting webgpu from people in game engines and scientific computing.
Zed editor switching graphics lib from blade to wgpu
11–20 of 321 posts
Re: Zed editor switching graphics lib from blade to wgpu
#12An interesting side effect of moving to wgpu is that in theory with some additional work, this could allow you to run Zed in a web browser similarly to how some folks run VSCode as a remote interface to the backend running on a server.
From the PR, it sounds like the switch to WGPU is only for linux. The team was reluctant to do the same for macOS/Windows since they felt their native renderer on those platforms was better and less memory intensive.
Yes, but they can add a flag to switch renderers on startup like they had for blade.
Re: Zed editor switching graphics lib from blade to wgpu
#13An interesting side effect of moving to wgpu is that in theory with some additional work, this could allow you to run Zed in a web browser similarly to how some folks run VSCode as a remote interface to the backend running on a server.
Well, not really. It means you have a renderer that is closer to being portable to web, not an editor that will run in web "with some additional work". The renderer was already modular before this PR.
Re: Zed editor switching graphics lib from blade to wgpu
#14An interesting side effect of moving to wgpu is that in theory with some additional work, this could allow you to run Zed in a web browser similarly to how some folks run VSCode as a remote interface to the backend running on a server.
Can this be done on a cheap AWS EC2 instance?
Sure it takes very little hardware power to do this, but Zed isn't actually setup for this yet. This is in theory and after a few more API's are adapted.
Re: Zed editor switching graphics lib from blade to wgpu
#15Is webgpu a good standard at this point? I am learning vulkan atm and 1.3 is significantly different to the previous APIs, and apparently webgpu is closer in behavior to 1.0. I am by no means an authority on the topic, I just see a lack of interest in targeting webgpu from people in game engines and scientific computing.
It's a good standard if you want a sort of lowest-common-denominator that is still about a decade newer than GLES 3 / WebGL 2.
The scientific folks don't have all that much reason to upgrade from OpenGL (it still works, after all), and the games folks are often targeting even newer DX/Vulkan/Metal features that aren't supported by WebGPU yet (for example, hardware-accelerated raytracing)
Re: Zed editor switching graphics lib from blade to wgpu
#16Oh, this is nice. Latest builds stopped working on panfrost because it does not announce the sufrace capabilities or something like that. Maybe I can have it back to working on the orange pi
Re: Zed editor switching graphics lib from blade to wgpu
#17An interesting side effect of moving to wgpu is that in theory with some additional work, this could allow you to run Zed in a web browser similarly to how some folks run VSCode as a remote interface to the backend running on a server.
From the PR, it sounds like the switch to WGPU is only for linux. The team was reluctant to do the same for macOS/Windows since they felt their native renderer on those platforms was better and less memory intensive.
> they felt their native renderer on those platforms was better and less memory intensive
This definitely would be worth some profiling. I don't think it's a given that their custom stacks are going to beat wgpu in a meaningful way.
Re: Zed editor switching graphics lib from blade to wgpu
#18Why was Blade ever decided upon? Is it older than wgpu?
I don't know why Blade was decided on, but it was started by Kvark who worked on WGPU for Mozilla for some time. I assumed it would be a good library on that basis.
Re: Zed editor switching graphics lib from blade to wgpu
#19Is webgpu a good standard at this point? I am learning vulkan atm and 1.3 is significantly different to the previous APIs, and apparently webgpu is closer in behavior to 1.0. I am by no means an authority on the topic, I just see a lack of interest in targeting webgpu from people in game engines and scientific computing.
For a text editor it's definitely good enough if not extreme overkill.
Other then that the one big downside of WebGPU is the rigid binding model via baked BindGroup objects. This is both inflexible and slow when any sort of 'dynamism' is needed because you end up creating and destroying BindGroup objects in the hot path.
Vulkan's binding model will really only be fixed properly with the very new VK_EXT_descriptor_heap extension (https://docs.vulkan.org/features/latest/features/proposals/V...).
Re: Zed editor switching graphics lib from blade to wgpu
#20An interesting side effect of moving to wgpu is that in theory with some additional work, this could allow you to run Zed in a web browser similarly to how some folks run VSCode as a remote interface to the backend running on a server.
Quoting maddythewisp from that PR:
> There is significant work beyond the renderer that would need to happen to run Zed in a browser - notably background tasks and filesystem/input APIs would need web/wasm-compatible implementations.