Yeah basically all of the above, especially fish and brewis, soups/stews, etc. Usually you soften it in some way before eating it.

In this case wgpu is just providing the surface texture for the window that the software rendered pixels are drawn into.

Softbuffer?

(I originally wrote this a few years ago but other people maintain it now)

I like softbuffer, but it owns its window and doesn't support as many events / integrations as winit.

You might be confusing softbuffer for minifb here, as softbuffer doesn't do any window handling of its own. All window management and event handling happens through winit (or another crate providing a HasWindowHandle implementation).

Oh, you're right! My bad

Yes, exactly this -- it's a fast and convenient way for my code to just write the pixels into a spot in RAM (the CPU's RAM, not VRAM) and have those pixels end up on screen. On modern architectures this nearly always goes through a GPU, so even if you're not using the GPU to accelerate your 3D rendering/math, you gotta deal with it just to put pixels on a screen at the end of the day. So that's what wgpu does for me.

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?

I think the parent is implying there are 1001 soc out there with some form of embedded gpu that probably have issues actually implementing webgpu. Like those in millions of Chinese tablets. Are they likely targets? Probably not now but in 5 years? Mainstream desktop hardware? No problem.

they just have to implement Vulkan, enough for it to run Dawn or wgpu

See Android for how much fun it is to debug OpenGL ES and Vulkan issues.

Not really, as mentioned, middleware does the job with much better developer tooling.

What I really would like to see is browser vendors finally providing WebGL and WebGPU debugging tools.

I think a decade has been more than enough for that.

Then again, no one is paying for browsers, so I guess I should not complain.

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

Thanks! Can't forget your help in the process.

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).

I did something similar with cosmic-text and glium, but it would be fun to have a vector rendering mode to do fancier stuff with glyph outlines and transforms for games and 3D stuff. And open source, of course.

I suppose vello is heading there but whenever I tried it the examples always broke in some way.

I have an abandoned proof-of-concept of something similar that might be worth checking out https://github.com/mxple/fim

Very interesting! I think I would get motion sickness judging by what I saw in the video, but I see what you're getting at with bezier rendering.

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.