kvark

We had a process at one company where you had to create an issue before filing a PR. I found it most non-sensical and introducing friction for no good reason. Very surprised to see the author suggesting it in the article.

Review is indeed the main bottleneck now for open source, and we need to solve it. Introducing more friction is hardly helping.

Author of the benchmark here, as well as Meganeura - one of the tested frameworks. Results are constantly being refined, gaps are filled, but it's hard to get more hardware coverage by myself. Would appreciate someone running it on Intel Arc GPUs, both discreet and integrated. Happy to answer questions about methodology!

Thank you for support!

Part of the problem with timing variety is frameworks not always picking the right gpu/backend.

If you want to inspect or tweak the setup, be my guest at https://github.com/kvark/inferena

Sadly the form doesn't even show up in Firefox. If they want to appeal to computer nerds, gotta anticipate not everyone will be on Blink engine.

The main problem with Vulkan isn't the programming model or the lack of features. These are tackled by Khronos. The problem is with coverage and update distribution. It's all over the place! If you develop general purpose software (like Zed), you can't assume that even the basic things like dynamic rendering are supported uniformly. There are always weird systems with old drivers (looking at Ubuntu 22 LTS), hardware vendors abandoning and forcefully deprecating the working hardware, and of course driver bugs... So, by the time I'm going to be able to rely on the new shiny descriptor heap/buffer features, I'll have more gray hair and other things on the horizon.

I've spent years playing with BWT and suffix sorting at school (some work can be found be names of archon and dark). It's a beautiful domain to learn!

Now I'm wondering: in the era of software 2.0, everything is figured out by AI. What are the chances AI would discover this algorithm at all?

I'm not employed by Zed, so I can't answer these questions. But the product itself is great!

Sure. Maybe that's the forcing function for them to nail down all the kinks. Example: https://github.com/kvark/blade/issues/205

Shipping Vulkan in production on Linux is a challenge. Chrome was dealing with it for a while. Recently, with Zed ported to Vulkan, we saw the variety of half-broken platforms and user configurations.

I'd recommend Blended to not close the door on OpenGL and instead keeping it as a compatibility fallback.

Oh irony. The article talks about exaggerated attention to success of individuals, like Zuck, being an issue in Silicon Valley. And yet the article itself talks about this AI Ad direction as something invented by evil Zuck. This isn't really about Zuck. Ultra-convincing ads will happen soon regardless of what Zuck does.

Firefox rendering is based on WebRender, which runs on OpenGL. The internals of WebRender are similar to gpui but with significantly more stuff to cover the landscape of CSS.

Those rotifers might have inspired the 3-body problem's concept of dehydration/rehydration as a skill to survive cataclysms.

David Baron was a distinguished engineer at Mozilla - not someone you fire at a whim. What makes you think he didn't leave voluntarily?

Super excited to see this reviving! We need more exploration into Linux structure: this world of hundreds distros barely different by their desktop environments - is too borong.

The gamedev ecosystem appears to be split between nalgebra (for Rapier users) and glam. Where does lin-alg fit?

In pinhole cameras, straight lines look straight. That's what a regular projection matrix gives you with rasterization. With non-pinhole cameras, straight lines look curved. You can't rasterize this directly. 3D Gaussian splats have an issue with this, addressed by methods like ray tracing. It's very useful to train on non-pinhole cameras, because in real world they can capture a wider field of view.

Locking DLSS-4 to 50xx only is unfortunate. I don't expect it to rely on any new superpowers. Otherwise - looks like a big step with the AI.

Because it has to go through gpu anyway before it reaches the screen, gpu can be more efficient at doing this (better battery, etc), and we are wasting time transferring the pixels to gpu where the splines would be much more compact.

They developed a content generation tool based on splines, as well as a rendering algorithm based on finding the closest splines to each point. They are claiming real-time rendering (4k at 120hz) on CPU... why not run this on GPU?

I disagree with the first point. Say, the compiler figured out your missing semicolon. Doesn't mean it's easy for another human to clearly see it. The compiler can spend enormous compute to guess that, and that guess doesn't even have to be right! Ever been in a situation where following the compiler recommendation produces code that doesn't work or even build? We are optimizing syntax for humans here, so pointing out some redundancies is totally fine.

That “.” substitution of an inferred type is going to fire back. I really appreciate when code has one simple property: you search a type by name and you get all of the places where it’s constructed. Makes it easy to refactor the code and reason about it with local context. It’s the case with Rust, but not C++ or Zig.

That’s a great business idea: sell a laptop survival kit for tough times.

You are comparing a live demo with many bots interacting with humans, versus a recording of a single bot in a factory by itself.

Quite often the meeting starts as “let me pick your brain on something“. This kind of expert advice from AI would save time and improve productivity of the team.

WGSL could be good for Khronos. It’s a modern language with an actual specification. It’s gaining users every day.

Having a standard CLI is definitely helpful. But does it have to be so hard to use? At what point would we acknowledge that we are being hostage by some random ideas put into ancient software, which just happened to survive?

I don't think calling for a stop of experimentation is the way. Nobody is going to take away your vi and bash any time soon.

Time will tell if this API is usable. In particular, the way resource synchronization works, and object renaming. Time will tell if it will perform better than WebGPU or other abstractions. Time will tell if it remains small in the presence of driver bugs that need working around…

I’m also sceptical about their new bytecode for a shading language. Parsing shaders at runtime was not a concern with WebGPU - it’s very fast. Even producing native shaders is fast [1]. It’s the pipeline creation that’s slow, and this bytecode wouldn’t help here.

[1] http://kvark.github.io/naga/shader/2022/02/17/shader-transla...

This rubs me the wrong way. Resource renaming is a high level concept, which was one of the features of OpenGL that all the modern APIs have successfully dropped. A modern low level GPU API should not do that.

Personally, it’s because they are not open source and not as fast.

Moving fast works well if you don’t know exactly what you’d be doing tomorrow. It’s an effective strategy of experimentation, regardless of VC money supporting it.