grovesNL

I think it would be interesting, especially for dynamic use cases where you can recompile the graph but use it many times. Although it's also probably pretty niche to get to that level of performance from these libraries.

At that point I'd guess most projects start to build up their own set of primitives (e.g., containing subsets of particular graphs) that they can hand-optimize better than these general purpose computation graphs. That's what I ended up doing so I could better control the tradeoff around which operations should be batched, heuristics around how cheap certain operations are (especially based on the elements at the time), more complex dependency tracking when working with data outside the graph, etc.

I think most non-trivial cross-platform graphics applications eventually end up with some kind of hardware abstraction layer. The interesting part is comparing how wgpu performs vs. something custom developed for that application, especially if their renderer is mostly GPU-bound anyway. wgpu definitely has some level of overhead, but so do all of the other custom abstraction layers out there.

Canada https://engineerscanada.ca/become-an-engineer/use-of-profess...

wgpu can run the WebGPU Conformance Test Suite for validation against the WebGPU specification. Was there something else you'd like to see?

Really excited to see WebGPU/wgpu ship in Firefox! Congratulations and thanks to Mozilla for supporting this.

Slug is patented but there are other similar approaches being worked on (e.g., vello https://news.ycombinator.com/item?id=44236423 that uses wgpu).

I also created glyphon (https://github.com/grovesNL/glyphon) which renders 2D text using wgpu and cosmic-text. It uses a dynamic glyph texture atlas, which works fine in practice for most 2D use cases (I use it in production).

Yes b'y, Newfoundland English is best kind sure.

wgpu has some options to access backend-specific types and shader passthrough (i.e., you provide your own shader for a backend directly).

Generally wgpu is open to supporting any Metal extensions you need. There's usually an analogous extension in one of the other backends (e.g., Vulkan, DX12) anyway.

wgpu has its own Metal backend that most people use by default (not MoltenVK).

There is also a Vulkan backend if you want to run Vulkan through MoltenVK though.

Scaffolding wasn’t a problem at all. Both used SPIRV-Cross for shader conversions at the time and focused on implementing the rest of the API. The shading language barely matters to the rest of the implementation. You can still use SPIR-V with wgpu on its Vulkan backend today for example.

SPIR-V was never in the specification, but both wgpu and Dawn used SPIR-V in the meantime until a shading language decision was made.

I don't think that's accurate. Creating a shading language is obviously a huge effort, but there were already years of effort put into WebGPU as well as implementations/games building on top of the work-in-progress specification before the shading language decision was made (implementations at the time accepted SPIR-V).

I'm not convinced by any of these arguments about "knowing how to program in WebGPU". Graphics 101 benchmarks are the entire point of a GPU.

You're totally right that it's the same hardware, but idiomatic use of the API can still affect performance pretty drastically.

Historically OpenGL and DX11 drivers would try to detect certain patterns and fast path them. Modern graphics APIs (WebGPU, Vulkan, DX12, Metal) make these concepts explicit to give developers finer grained control without needing a lot of the fast path heuristics. The downside is that it's easy to write a renderer targeting a modern graphics API that ends up being slower than the equivalent OpenGL/DX11 code, because it's up to the developer to make sure they're on the fast path instead of driver shenanigans. This was the experience with many engines that ported from OpenGL to Vulkan or DX11 to DX12: performance was roughly the same or worse until they changed their architecture to better align with Vulkan.

Simple graphics benchmarks aren't a great indicator for relative performance of graphics APIs for real use cases. As an extreme example, rendering "hello triangle" for Vulkan vs. OpenGL isn't representative of a real use case, but I've seen plenty of people measure this.

It's "Slow" because it has more overhead, therefore, by default, I get less performance with more usage than I would with WebGL.

It really depends on how you're using it. If you're writing rendering code as if it's OpenGL (e.g., writes between draw calls) then the WebGPU performance might be comparable to WebGL or even slightly worse. If you render in a way to take advantage of how modern graphics APIs are structured (or OpenGL AZDO-style if you're more familiar), then it should perform better than WebGL for typical use cases.

Here's an example of Bevy WebGL vs Bevy WebGPU

I think a better comparison would be more representative of a real game scene, because modern graphics APIs is meant to optimize typical rendering loops and might even add more overhead to trivial test cases like bunnymark.

That said though, they're already comparable which seems great considering how little performance optimization WebGPU has received relative to WebGL (at the browser level). There are also some performance optimizations at the wasm binding level that might be noticeable for trivial benchmarks that haven't made it into Bevy yet, e.g., https://github.com/rustwasm/wasm-bindgen/issues/3468 (this applies much more to WebGPU than WebGL).

They're 10k triangles and they're not overlapping... There are no textures per se. No passes except the main one, with a 1080p render texture. No microtriangles. And I bet the shader is less than 0.25 ALU.

I don't know your exact test case so I can't say for sure, but if there are writes happening per draw call or something then you might have problems like this. Either way your graphics driver should be receiving roughly the same commands as you would when you use Vulkan or DX12 natively or WebGL, so there might be something else going on if the performance is a lot worse than you'd expect.

There is some extra API call (draw, upload, pipeline switch, etc.) overhead because your browser execute graphics commands in a separate rendering process, so this might have a noticeable performance effect for large draw call counts. Batching would help a lot with that whether you're using WebGL or WebGPU.

Only 10k non-overlapping triangles can bring my RTX GPU to its knees

Your benchmark doesn't match the experience of people building games and applications on top of WebGPU, so something else is probably going on there. If your benchmark is set up well, you should be limited by the fill rate of your GPU, at which point you should see roughly the same performance across all APIs.

On my computer, the average Unity game with shadows, shaders 'n stuff takes 5% GPU and a simple WebGPU demo takes 7%.

GPU usage isn't a great metric for performance comparisons in general because it can actually imply the inverse depending on the test case. For example, if the scenes were exactly the same, a lower GPU usage could actually suggest that you're bottlenecked by the CPU, so you can't submit commands fast enough to the GPU and the GPU is sitting idle for longer while it waits.

There's plenty of room for both approaches: a lot of projects can benefit from using a platform-agnostic API like WebGPU (web or native) directly, others might want to use engines. Anecdotally I use WebGPU (through wgpu) in a commercial application for a visualization, and would've never bothered to apply Vulkan or DX12 for that otherwise.

Documentation will keep improving with time. There have already been a number of high-quality tutorials and references created over the past few years, for example:

https://webgpufundamentals.org/ for JavaScript/the web API

https://sotrh.github.io/learn-wgpu/ for Rust (web or native)

https://eliemichel.github.io/LearnWebGPU/ for C++

Multi-threading would be really nice, although it's not clear to me how to parallelize this in a way where the synchronization cost wouldn't regress performance. Tasks are prioritized, so each booking happens in sequence (i.e., each task needs to know where the higher priority tasks ended up being placed). There are cases where it's possible to determine whether they might be fully isolated (e.g., if one booking couldn't possibly affect another) to run those in parallel, but sometimes determining that might be non-trivial too.

I have been experimenting with a few caching approaches, but the caches tend to be invalidated so often that they didn't seem to help much yet. Some of the coarser-grained caches mentioned in some of the other comments could be interesting though, as a way to quickly skip over entire regions when the remaining availability intervals are too short for typical queries.

Do you mean time was used as the key for the hashmap? What was the vector used for in that setup?

All great points, thank you! I'll need to think about this some more.

For context, queries are trying to find the next available equipment for tens of thousands of tasks, so hundreds of thousands of queries isn't too bad relative the to the amount of tasks. Equipment candidates are matched based on their capabilities (some equipment might support A or B, while others support B or C) and tasks might require certain combinations. This might complicate the multiset slightly but it seems like a good idea.

The ordered map I'm currently using handles adjacent available intervals by automatically coalescing them together, so I'm definitely taking advantage of that.

Thanks for the reference! This looks like an implementation of a disjoint set/union-find data structure. I think it could be an interesting direction to explore by adapting union-find to handle intervals efficiently, or maybe apply some of the union-find amortized operations tricks to another interval-based tree or similar.

Thank you! I should have clarified that my map does currently store free time slots instead of booked time slots, but either representation would be ok if it would be beneficial for the data structure.

Sounds interesting, I’ll check it out, thanks! Skimming through it quickly it seems like it may be focused on actual running timers instead of tracking intervals, but some of the ideas might still apply to this problem.

Thank you, I should look into these more. I actually came across them earlier but it wasn’t obvious that these would outperform a plain sorted `Vec` with binary search, which seemed to have slightly worse performance than the ordered map I’m currently using. my understanding is that some of the bioinformatics-oriented interval trees assume intervals are mostly static, so they don’t support updates very well without expensive tree rebuilding after each batch of updates.

That makes sense. I tried dense bit sets but storing a transition bitset could be interesting. That sounds similar to an inversion list compressed into a bitset.

The rank-select sounds like a great idea and seems like it would work great for mostly static intervals, but updates are pretty common in my case.

Thank you for the reference, I’ll take a look! I like the idea of being able to use connected components somehow if it could avoid some of the overhead of range queries during updates. I’ve been considering whether there might be a way to apply union-find in a way that would still be faster than some kind of bitset representation.

This sounds interesting! From my understanding it’s similar to an inversion list but storing explicit in/out instead of deriving it from the element’s rank (i.e., index if it’s stored as an ordered `Vec`) mod 2.

I’m not too worried about storage requirements though so I wonder if having to search the adjacent node to determine the duration vs. The current representation. I could see how this could improve update performance though.

Augmenting tree nodes and/or keeping track of min/max duration across coarser regions seems like a good approach. I could see each layer being represented in-tree like you described, or as separate layers each with their own granularity, where they could help to tighten bounds during range queries.

Do you know of any libraries implementing this?

The duration granularity is days right now, but the total duration of the map might extend out for tens of years or so. I did try bucketing them into hundreds of day long intervals but it didn't seem to help very much.

Right, this calculation runs on the client and assumes the clients are fast enough. This helps a lot with interactivity because the network stack isn’t involved at all.

It could be interesting to optionally offload some compute to much faster servers when it would be useful, but that introduces request/response latency overhead too.

In this specific case, it’s part of an automatic scheduler that performs hundreds of thousands of range queries in a real-time interactive use case, so small improvements here can make a huge difference to the overall feel of the application. A lot of scheduling applications take seconds or minutes to run queries like that, but that would be way too slow for real-time interactions like I’m doing.

The current approach I’m using takes tens of milliseconds for some large test cases (which is great!), however I’d like to improve on it more so I could eventually run much bigger cases at real-time interactive speeds too.