Orochi VS wgpu

While you're waiting for the HIP SDK to release, check out Orochi as an alternative https://github.com/GPUOpen-LibrariesAndSDKs/Orochi

You can't run CUDA binaries directly. But you can use a wrapper library like Orochi to run both CUDA and HIP using a single binary that dynamically links with CUDA/HIP libraries at runtime https://github.com/GPUOpen-LibrariesAndSDKs/Orochi

I stumbled across orochi from AMD while looking for their FSR2.0 implementation, which basically boils down to being a wrapper over Cuda and HIP. I don't know if it is still maintained or functional, but heres the link if anyone is interested: https://github.com/GPUOpen-LibrariesAndSDKs/Orochi

Sorry I don’t know much about Rasberry PI. Which rendering API are you using? WGPU fullly supports Vulkan on Linux and GLES3 as “best effort” (from their readme).

Not anymore, we only used it for BITGUN. The game in the devlog is made purely in Rust, built on top of https://wgpu.rs/. We have some other projects that use Unity though.

Another route could be using an abstraction over Vulkan (faster, more efficient, more difficult): bgfx, dawn, magma, or wgpu (Rust).

My focus this week has been on planning and assisting with architecture changes that help us fully integrate the node graph compositing engine we built over the past year. Upcoming tech we're working towards includes full utilization of the node graph to power all our layers; adopting WebGPU (now out in Chrome) into our editor using WGPU and rust-gpu; setting up a Tauri build and deployment; and building a backend web service to handle user accounts for document storage, hosting rustc to compile custom graphics effect nodes written by users in Rust, and Stable Diffusion image generation on AWS EC2 GPU instances.

My mistake, I remembered that they plan to use DX12 by default on Windows, but there's still blocking issues in the DX12 backend

https://github.com/gfx-rs/wgpu/issues/2719

WebGPU can be used outside of the browser through native libraries:

https://github.com/gfx-rs/wgpu

https://dawn.googlesource.com/dawn

Some WASM engines also have WebGPU support already, but unfortunately only for 'offscreen rendering' or compute tasks (e.g. for writing windowed apps, there's a window system glue layer missing).

Why is the hello-compute example able to write to a buffer without a layout the compute pipeline ( https://github.com/gfx-rs/wgpu/blob/trunk/wgpu/examples/hello-compute/main.rs )?

Tridify-rs (Originally named Ldrawy and based on Open GL) is a really simple but flexible and lightweight low-level GPU rendering framework based on Wgpu to create your own frameworks, engines, emulators... You name it!

I have been contemplating the development of an image manipulation tool as a side project during my university studies. After some consideration, I have decided to implement it in Rust using wgpu for rendering and compute shaders. The supported platforms will include desktop and desktop web. As an image manipulation tool requires more than just a viewport, it also needs some form of GUI around it. Therefore, the choice of GUI library, if any, becomes quite relevant from an architectural perspective. I have been exploring egui, but I have encountered a problem. Since it employs immediate mode rendering, the entire content of the application needs to be re-rendered every time a user interacts with it, such as moving their cursor over the window. This can result in a power draw that presents issues for portable devices like laptops.

There is also [Vulkano](https://github.com/vulkano-rs/vulkano). It has a safe high level api and lower level layers, all the way down to [ash](https://github.com/ash-rs/ash) which is more or less raw vulkan. It's more explicit and verbose than [wgpu](https://github.com/gfx-rs/wgpu) though, so maybe try wgpu first and see how you like it.