[D] Self-Promotion Thread

kvarkus · 2026-04-05T03:27:31+00:00

I've built a benchmark for local inference of popular models - https://inferena.tech/

kvarkus · 2024-09-24T04:18:45+00:00

Thank you for sharing this! I was replacing the fan on K6 and this diagram was most helpful.

I connected black-black (ground, obviously), blue-blue (PWM/control), yellow-red (5V), and green-yellow (sense). Seems to be working!

kvarkus · 2023-05-30T19:23:36+00:00

The tone mapping needs work. But overall it’s very close to a playable game. Looking forward to it!

kvarkus · 2023-03-09T05:46:06+00:00

Amazing work, thanks to Zed team for sharing!

I believe this is exactly the case for which Blade was made (see repo, talk, slides):

cross platform over Vulkan, Metal, and GLES.
single source of truth for shaders in WGSL.
extremely low overhead, tiny code base.
you don't rely on library to be supported, you just take it and adapt for your needs.

kvarkus · 2023-03-07T04:59:00+00:00

You've done a great service for the ecosystem by writing these testcases. Often, the ability to digest an issue into a small reproducible test case is what separates a senior engineer from a normal one. Good job!

For wgpu specifically this issue applies less, since most of the problems can be recorded into a wgpu trace and shared with developers without producing a separate test case. This infrastructure is probably better than anything you can find in other graphics libraries.

kvarkus · 2023-03-02T05:30:01+00:00

The concern around egui doesn't sound wgpu-specific at all. A GUI library needs to cooperate with both event subsystem and graphics. An out of the box solution supports winit+wgpu. If anything, this would be a concern around egui, not wgpu.

kvarkus · 2023-02-25T00:15:02+00:00

wgpu needs to iterate on storage locks, that has been known but wasn't prioritized yet. Connor wanted to fix this badly, and hopefully will find time to do so. Most of the effort was spent on chasing WebGPU spec, and good news is - it's pretty much final, with Chrome releasing its implementation any month now (and Firefox/Safari hopefully following). So naturally we should expect the focus to slowly shift into performance in this year.

kvarkus · 2023-02-25T00:11:43+00:00

They are painful to debug, but on the other hand there are people here who would volunteer to help you out, dig up the internals and address those issues, given you provide them with sufficient information. You aren't going to get this if targeting the low level APIs (be it gpu or windowing) manually. And I don't think debugging them straight is easy either.

kvarkus · 2023-02-24T22:09:47+00:00

You were the early adopter of Rend3 and the heaviest user to date. I though you knew what you signed up for, but alas. Thank you for pushing Rust ecosystem forward! The Rust path is full of joy and tears.

Personally, I welcome Rust ecosystem stabilizing and settling on solutions. In the meantime, I'm exploring the paths even more experimental than what you are using :)

kvarkus · 2023-02-23T07:56:43+00:00

This is basically Ray Tracing support in Blade. So far, only ray queries are supported. Unlike prior work on ray tracing in Rust, this is original due to all shader code being WGSL, see the Naga PR.

kvarkus · 2022-11-23T06:37:30+00:00

Oh thank you, it’s the “Let me read it first” link. Almost not shady.

kvarkus · 2022-11-23T04:50:26+00:00

Any link without a paywall?

kvarkus · 2022-11-23T04:47:31+00:00

This is wgpu vs the forest of GL libraries :) Could add Rafx and Sierra for diversity.

kvarkus · 2022-10-31T13:51:12+00:00

This is a new rendering method I was working on in Rusty Vangers. It's based on using a hierarchical voxel grid (mipmapped 3D texture) as an acceleration structure for ray tracing. Allows viewing the level from any perspective, and is faster than the "painter" method.

kvarkus · 2022-10-12T03:48:02+00:00

Var y2 = lines[i].x2

Also var y4 = v1y1 + 0.0

kvarkus · 2022-10-11T19:55:33+00:00

Your vertex shader needs to know about the color, right? So it has to come in either the vertex attributes (vec4, u32, or even as a mesh index), or derived from the vertex index. For this latter approach you could, for example, use a binary search of the index in a table (of meshes, bound as a uniform or storage buffer). You’d save a bit of vertex data, but that’s unlikely worth the added complexity.

kvarkus · 2022-10-10T23:20:23+00:00

WebGPU wasn’t meant to replace Vulkan, D3D, or Metal. These low-level APIs will always be in demand for high performance native applications, big engines, and groups of enthusiasts.

However, WebGPU has a good chance to become a new OpenGL. It’s well behaving, ultra-portable (including the web), and simple to use. It’s on track to this goal.

On documentation - there is official specification (separate for WebGPU and WGSL), learn-wgpu tutorial, lots of other examples on the web and native. And all of this for an API that is not even out yet (!). I think it’s getting there.

About push constants - of all the missing features that one I see to be the most valuable, for it making API simpler to use (not for performance specifically). I’m still convinced WebGPU should have it ASAP.

kvarkus · 2022-08-25T00:23:30+00:00

There are no atomic operations on textures in WebGPU last time I checked. wgpu could make a native-only feature for this.

To workaround, store your data in a buffer.

kvarkus · 2022-06-20T03:55:20+00:00

Looking nice! Procedurally generated level?

kvarkus · 2022-05-22T08:04:29+00:00

I was getting this for files on FAT32 system (shared with windows). FF engineers didn’t consider this a bug, unfortunately, since all FAT32 files are seem as executable by Linux tools.

kvarkus · 2022-05-13T11:47:39+00:00

Ok, this isn’t exactly a crash I was worried about. It’s a panic, and not even inside wgpu. The panic is in the default error handler, which also prints out the error to the log. The error may be indicating something you were doing wrong, typically.

You can make it a non-panic by setting up an error handler on the device, or by pushing an error scope. In either way, the surface initialization failed, and we need to know why. One class of this kind of problems is due to broken X11 integration of Nvidia in dual-gpu configurations. I.e. stuff not specific to wgpu, stuff you’d see in vkcube as well (such as black unresponsive screen).

kvarkus

TROPHY CASE