▲ | jblandy 4 days ago | |
There have been a bunch of significant improvements to WGPU's performance over the last few years. * Before the major rework called "arcanization", `wgpu_core` used a locking design that caused huge amounts of contention in any multi-threaded program. It took write locks so often I doubt you could get much parallelism at all out of it. That's all been ripped out, and we've been evolving steadily towards a more limited and reasonable locking discipline. * `wgpu_core` used to have a complex system of "suspected resources" and deferred cleanup, apparently to try to reduce the amount of work that needed to be done when a command buffer finished executing on the GPU. This turned out not to actually save any work at all: it did exactly the same amount of bookkeeping, just at a different time. We ripped out this complexity and got big speedups on some test cases. * `wgpu_core` used to use Rust generics to generate, essentially, a separate copy of its entire code for each backend (Vulkan, Metal, D3D12) that it used. The idea was that the code generator would be able to see exactly what backend types and functions `wgpu_core` was using, inline stuff, optimize, etc. It also put our build times through the roof. So, to see if we could do something about the build times, Wumpf experimented with making the `wgpu_hal` API use dynamic dispatch instead. For reasons that are not clear to me, switching from generics to dynamic dispatch made WGPU faster --- substantially so on some benchmarks. Animats posts frequently about performance problems they're running into, but when they do it's always this huge pile of unanalyzed data. It's almost as if, they run into a performance problem with their code, and then rather than figuring out what's going on themselves, they throw their whole app over the wall and ask WGPU to debug the problem. That is just not a service we offer. | ||
▲ | ossobuco 4 days ago | parent | next [-] | |
He's reporting a 23% drop in performance and seems to have invested quite some time in pinning down what's causing it, plus he's provided a repro repository with benchmarks. I honestly don't get your annoyed response; any OSS project wishes they had such detailed bug reports, and such a performance regression would concern me very much if it happened in a project I maintain. | ||
▲ | Animats 4 days ago | parent | prev | next [-] | |
This is in reference to [1]. | ||
▲ | jillyboel 3 days ago | parent | prev [-] | |
What? They even provided a benchmarking tool. You should be ecstatic at users providing such detailed reports. Most projects just attract reports that go like "its slow, fix it!!111" |