The lack of word wrapping, that we have grown so accustomed to on the Web, makes this article nearly illegible.

Fixed! Thanks for the heads-up. I'm used to writing in Korean where wrapping is rarely an issue, so I missed this during the English migration. It's updated now—thanks for the patience!

Love it. Double bonus points if we could somehow add hardware ray tracing, which is missing from the browser WebGPU implementations. I'll definitely give this a shot with my 3D interactive WebGPU chessboard. A desktop implementation opens up the possibility of publishing on steam and other services which all expect a desktop app.

So in theory it should be possible, but it might require customizing the Dawn or wgpu-native builds if they don't support it (this is providing the JS bindings / wrapper around those two implementations of wgpu.h). But I've already added a special C++ method to handle draco compression natively, adding some mystral native only methods is not out of the question (however, I would want to ensure that usage of those via JS is always feature flagged so that it doesn't break when run on web).

Did you write your WebGPU chessboard using the raw JS APIs? Ideally it should work, but I just fixed up some missing APIs to get Three.js working in v0.1.0, so if there are issues, then please open up an issue on github - will try to get it working so we close any gaps.

Here's a dawn implementation with support for ray tracing that was implemented a number of years ago but never integrated into browsers. Perhaps it will help?

https://github.com/maierfelix/dawn-ray-tracing

Yes, chessboard3d.app is written with raw JS APIs and raw WebGPU. It does use the rapier physics library, which uses WASM, which might be an issue? It implements its own ray tracing but would probably run 10x faster with hardware ray tracing support.

I think you'd get a lot of attention if you had hardware ray tracing, since that's only currently available in DirectX 12 and Vulkan, requiring implementation in native desktop platforms. FWIW, if the path looks feasible, I would be interested in contributing.

WASM shouldn't be an issue since the draco decoder uses it - but it may only work with V8 (for quickjs builds it wouldn't work, but the default builds use V8+dawn). Obviously with an alpha runtime, there may be bugs.

I think it would be super cool to have some sort of extension before WebGPU (web) has it. I was taking a look at the prior example & it seems like there's good ongoing discussion linked here about it: https://github.com/gpuweb/gpuweb/issues/535. Also I believe that Metal has hardware ray tracing support now too?

Re: Implementation, a few options exist - a separate Dawn fork with RT is one path (though Dawn builds are slow, 1-2 hours on CI). Another approach would be exposing custom native bindings directly from MystralNative alongside the WebGPU APIs - that might make iteration much faster for testing feasibility. The JS API would need to be feature-flagged so the same code gracefully falls back when running on web (did this for a native draco impl too that avoids having to load wasm: https://mystralengine.github.io/mystralnative/docs/api/nativ...).

"I really hate this damn machine. I wish that they would sell it. It never does what I want it to, only what I tell it."

Add vscode. Add a list of models, since many tools allow you to select which model you use.

Bravo! Not a single mention of LLMs changing the calculus.

In some situations it may be politically useful to pretend that an LLM makes things faster because that is what your boss wants to hear though.

Creating a good product requires lots of interaction with your target customers. You can call the "sales" in the beginning, but it's really understanding how to tweak your product from an idea to solve a problem into something that fits into the customer's workflows and solves their problems. The only way to really validate the product is to see who pays money for it.

What about incentivizing switching the building from commercial to residential? Given that commercial brick and mortar are generally on a downward trend, and the need for housing continues to increase, it would seem better to switch the property zoning in the long run. Since I'm clueless about the financial details of commercial real estate, I'm sure this proposal is full of holes, but, as a rule, I prefer incentives rather than penalties to motivate change.

More details!? What are we looking at? Why is is breathing? I love these artistic uses of interactive 3D and want to know more about how it works and what motivated the artist.

I did some consulting for Jimmy at Apple Daily, and he took me out to the best street-food lunches I ever had. His car took us to a busy street corner, where four of us had a huge lunch for two hours while the car disappeared. When the car magically showed up at the end, Jimmy told me that he paid ~$20 for that amazing food for all of us. No pretense. A lovely man. Very sad.

For NVIDIA cards, you can use NSight. There's also RenderDoc that works on a large number of GPUs.

RenderDoc is very cool, but more of a high level debugger, I guess? It's also good to analyze performance issues, e.g. when working with QML and QSG_VISUALIZE=overdraw / batches (both very high level) don't cut it anymore, or to get a different perspective. Watching a scene getting drawn API call by API call is fun.

RenderDoc is mostly a frame debugger, although it does support stepping through shaders as well which can be super useful. But for real performance analysis I would use PIX if you target D3D12 or RGP and Nsight for Vulkan. I'm at a Vulkan and Metal only shop and I wish I could use PIX for my every day work, since it also has excellent support for Intel GPUs.

nsys and nvtx are awesome.

many don't know but you can use them without GPUs :)

That's true. It's pretty good for all kinds profiling. I especially like the python GIL profiler of nsys.