Patrick Walton

Patrick Walton

@pcwalton.turbofishstudios.com

Programming languages and graphics person. Rust compiler and Firefox contributor. Currently working on an unannounced project!

2.6K followers49 following176 posts

BSN syntax gets worse and worse, with more sigils being added and the syntax getting ever more confusing. The fact that LALRPOP was abandoned partially because of the fact that the grammar isn't LR(1) should have been a canary in the coal mine. -- as a list separator is a truly baffling decision.

Bevy@bevy.org

Bevy 0.20 is out now! It features Solari and DLSS improvements, better BSN syntax, BSN "ready" events, WESL is now Bevy's shader language, more UI widgets (color picker, scrollable list views, dropdowns), Sprite Materials, Extended 2D materials, Pan Orbit Camera, and more! bevy.org/news/bevy-0-...

Bevy's scene format is frustrating because it's the best scene format out there, but it could have been far better. Lack of a delimiter between entities is such an own-goal and everyone is going to be tripping up on this forever.

One programming language "lane" that's still wide open is an native AOT compiled language with a high-performance, tracing, generational, moving GC. Imagine something like C# or C++ but safe and in which malloc is 5 CPU insns so you don't have to worry about allocating all the time.

These days most of my attempts to improve Bevy's 3D performance fail. This might seem disappointing, but actually in my experience this is a *good* thing! It indicates that the low-hanging fruit is largely gone and Bevy's 3D is getting increasingly close to optimal.

I read a bunch of folks saying "I tried Nushell and went back to Bash" and I'm like, how on earth. I do so much simple data manipulation and automation in Nushell that going back to having to use sed/awk, or reaching for Python and writing 3× the code, feels miserable. Do others just… not do that?

This mess is a stress test of Bevy 0.19 with 2,000,000 instances of 100,000 separate meshes. Runs at 60 FPS on my laptop. Each of the 2M mesh instances is a separate entity. There's no special "instanced mesh" component needed; the GPU driven rendering does all the batching automatically.

A graphical frontend to Nushell in which you can drag in commands to create pipelines might be, like, the ideal form of visual programming. It might even be not terrible on a phone for “I need to format this data real quick” throwaway stuff.

Gone too long without saying this so to reiterate yet again: • Reference counting does not prevent GC pauses; you can deallocate a lot of objects at once • It is possible to write RC that cleans up cycles and as a user you should demand this • Most tracing GCs are bad and you should demand better

Maybe it's just me, but it feels like, more than any project I've worked on, the Discourse around Bevy is disproportionately just incorrect. Not sure if it's because: * Bevy moves so fast (aside from the editor); * Bevy is relatively niche; * Gamedev attracts a lot of confidently incorrect people

Often times when people say "oh, there's room for X and Y to coexist", that's just wishful thinking and either X or Y ends up totally displacing the other in the end. But regarding Go and Rust, that's actually ended up being true! Definitely a nice outcome.

Really excited about the performance benefits coming in Bevy for mega-worlds. With all my patches we're starting to be able to render millions of mesh instance entities with hundreds of thousands in view with just a handful of drawcalls.

My goal is to make Bevy "just work" when scaling to millions of entities. You shouldn't have to use a special DOTS/MassEntity/etc. system to scale. There's just one kind of entity, and the ECS scales seamlessly from small to large.

Patrick Walton reposted

hacked and adapted Bevy's existing atmosphere support in last night, re-enabled lighting, and made a few more tweaks. enjoy some sunsets #bevy

philpax@philpax.me

extended weekend project: a completely standalone first-person Google Earth viewer with physics #bevy yes, you really can go anywhere

In my GPU clustering branch, which is making its way through review, Bevy 0.19 can render ~8,000 visible lights (of 100k total) at about 200 FPS on my laptop 4070. This also adds the infrastructure for particle systems to emit lights entirely from GPU without any CPU involvement at all.

The GPU clustering itself runs at about 110 μs, a speedup of 30x over Bevy 0.18 on this stress test. It automatically resizes the clusters as necessary for best performance. There are no arbitrary limits on the number of lights or clusters. The same system handles light probes and decals too.

I'm taking no position on the technical merits of Godot here, but I will say that this is the exact kind of thing people used to say about GCC right up until it and LLVM killed all the other compilers because they couldn't keep up.

My fork of Bevy Hanabi, Hanabi-Batched, has been updated to support 0.18 and has many more improvements, such as lookup textures, PBR particles, and GPU mergesort for ribbons: github.com/pcwalton/bev... If you're looking for a way to use Hanabi on 0.18, feel free to grab it!

github.comGitHub - pcwalton/bevy_hanabi: A fork of Bevy Hanabi, the GPU-driven VFX system for Bevy, with improved performance and functionalityA fork of Bevy Hanabi, the GPU-driven VFX system for Bevy, with improved performance and functionality - pcwalton/bevy_hanabi

Bevy 0.18 is out! My main contribution to this one was portals and mirrors: github.com/bevyengine/b...

github.comImplement the infrastructure needed to support portals and mirrors. by pcwalton · Pull Request #13797 · bevyengine/bevyImplement the infrastructure needed to support portals and mirrors. Bevy currently supports multiple cameras and rendering to off-screen render targets, so one might naïvely think that the engine h...
Bevy@bevy.org

Bevy 0.18 is out now! It features Atmosphere Occlusion and PBR Shading, Generalized Atmospheric Scattering Media, Solari features, PBR Fixes, Font Variations, Automatic Directional Navigation, Fullscreen Materials, Cargo Feature Collections, Camera Controllers, and more! bevy.org/news/bevy-0-...

Strangest issue I've encountered in the wild when fuzzing: `vaddps xmm0,xmm0,xmm1` and `vaddps xmm0,xmm1,xmm0` are *not* the same on x86 when it comes to which NaN payload it chooses. But LLVM will reorder the arguments anyway! Lesson learned: always canonicalize your NaNs when fuzzing.

"Analyzing the Performance of WebAssembly vs. Native Code" places a lot of the blame for the worse performance of wasm on register spills, esp. with JS engines' reserved registers. Sounds like APX could actually help by bumping the register count from 16 to 32? ar5iv.labs.arxiv.org/html/1901.09...

ar5iv.labs.arxiv.orgNot So Fast: Analyzing the Performance of WebAssembly vs. Native CodeAll major web browsers now support WebAssembly, a low-level bytecode intended to serve as a compilation target for code written in languages like C and C++. A key goal of WebAssembly is performance pa...

I filed an issue on what I think the minimum set of instructions that wasm needs to efficiently implement JITs of systems with MMUs is: try-load and try-store. github.com/WebAssembly/... Interested in feedback. (From what I see, this would enable fast emulation on non-jailbroken iOS.)

github.comAdd “try-load” and “try-store” instructions · Issue #23 · WebAssembly/memory-controlJITting emulators like http://copy.sh/v86 incur significant overhead from having to check page tables on every memory access. Traditionally, emulators implement this by trapping SIGSEGV. The signal...

Well, I guess nommu doesn't help that much when you still need to invalidate jitcode. You're paying most of the cost of a TLB in that case... Wish wasm had better support for setting page permissions and catching faults.

Project that'd be fun but that I have no time for: Compile and run native code on-device on iOS by running macOS (or Windows?) interpreted in a VM on-device, and have the VM talk to the iOS device via a tiny device ($5 microcontroller?) you plug into the USB port that loops the USB back.

I noticed that x86 APX has a prefix that allows for 3-operand insns (e.g. add rax,rbx,rcx instead of mov rax,rbx; add rax,rcx). I wonder what the advantage of that over the 2 instruction pair is? Couldn't the CPU fuse the latter instruction pair into effectively a 3-operand insn?