3 ms·
The thing about graphics in general is that typically you want to use whatever the underlying hardware gives you to get the best performance. This can conflict
by wtetzner 5y ago
The thing about graphics in general is that typically you want to use whatever the underlying hardware gives you to get the best performance. This can conflict with the law of least power, but so what?
You can’t optimize for everything, so you decide what tradeoffs make the most sense.
- CyberRabbi 5y agoI think you and likely most people reading this discussion are missing the point. Wgpu is fine and even great as a general purpose API but it’s inappropriate as an application-specific abstraction for a graphics backend. It should absolutely be used to implement the latter. Compare this to the Rust compiler. Rust uses MIR as its intermediate compiler IR for Rust-specific optimizations, because it retains Rust-specific semantics, before it compiles down to LLVM bitcode. If it used LLVM bitcode as its native IR then it would be difficult to implement Rust-specific optimization passes. In this case an application specific graphics API is analogous to MIR and wgpu is analogous to LLVM.
- wtetzner 5y agoSure, but if you’re never going to do any MIR-level optimizations, then there’s no reason to implement it. Similarly for graphics APIs. If at some point in the future you need to support a platform not supported by wgpu, you can add the abstraction layer at that time. Doing it before then doesn’t really buy you anything. You might never need it, and if you do, you’ll have a much better idea of what it should look like once you know what the new platform actually looks like.