←back to thread

783 points Keavon | 2 comments | | HN request time: 0s | source

For the past three years I've been building what I hope will be the next Blender, tackling the lack of any good 2D design or image editing tools outside the Adobe monopoly. This was our first year participating in Google Summer of Code and this Q3 update includes the big payoff from that, covering the most progress we've made so far as a project. If you're a Rust dev, consider getting involved as we apply for the next GSoC in the new year— you could be our intern next summer :)

Q3 progress report: https://graphite.rs/blog/graphite-progress-report-q3-2024/

Show context
lacoolj ◴[] No.41853909[source]
This is really cool but I have an RTX 4080 and it's really struggling to open and subsequently manipulate the example art.

Maybe just because it's in the browser?

replies(2): >>41854076 #>>41857013 #
Keavon ◴[] No.41854076[source]
That'd be because it's all CPU-based at the moment . So your 4080 is taking a vacation while your CPU hits the gym. That's obviously not ideal, but you'll have to trust me that it is due to long-term architectural planning reasons and not a blatant disregard for sensible development practices. Our node graph engine is really advanced—it's actually a scripting language built upon Rust and its type system—which will have some very sizable benefits once it's done being built. But right now, it means vital things like GPU compute have been blocked by a towering pile of other engineering work. But we've nearly completed those prerequisites and should be able to unlock GPU compute in the early parts of next year (this is also blocked on Firefox and Safari shipping WebGPU support, required to use compute shaders in the browser— and on us having the time to support Windows, Mac, and Linux builds via [Tauri](https://tauri.app/)).

In short, please be patient :) The app's architecture is designed with performance that'll make your CPU and GPU scream, but it's a big job building all of it. Especially for raster imagery, that's where a CPU-bottlenecked render pipeline is especially affected. But next year is the year we move on from vector graphics to raster once the GPU is utilized in the render pipeline.

Thanks for taking a look!

replies(1): >>41854406 #
1. john01dav ◴[] No.41854406[source]
When you start supporting GPUs, what APIs do you plan to use (cuda, vulkan, dx, etc.)? It would be quite unfortunate to use a non-vendor-neutral API (for both OS and GPU vendor). I would probably use wgpu or vulkan for this.
replies(1): >>41854463 #
2. Keavon ◴[] No.41854463[source]
Everything will be using compute shaders for the foreseeable future. [WGPU](https://wgpu.rs/) abstracts that to work with WebGPU on browsers, DirectX/Vulkan on Windows, Metal on Mac, and Vulkan on Linux and Android. There may be opportunities to explore vendor-specific options like CUDA in the far future to leverage a further increase in performance, but compute shaders are portable and nearly as good.