ecs: struct components in GPU accessors, packed u64/u128 fields, and the cost of staged archetype moves

オープン
  • 何か問題がありますか？
#271 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
38/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript, wasm
領域
backend, performance

調査の方向性

Start with src/interface/gpu/accessors.ts and layoutOf to see how struct layouts are handled, then trace row and kernel access to component values and their change stamping. Check the existing benchmark and profiling entry points, including src/perftest/birth.ts, for the packed-field and command-encoding costs. Done means documenting current u64/u128 support and lane change behavior, with measurements that compare packed and separate fields and define the requested accessor support.

索引モデルが issue の本文から書いたものです。

説明

Found while consolidating a voxel renderer's per-entity data (the mecs app, @adobe/ecs 0.3.2). Two things to verify or add, and the measurements that motivate them.

Why

Each voxel carries denormalized, derived values as separate components: a look (color 4×f32, metallic/roughness 2×f32, emission 3×f32, fade f32, refraction 2×f32) and a shade (exposure u32, occlusion 2×u32, sunlight u32). They are written by different systems at different times, so a voxel is born in four stages (spawn, then +cell, +look, +shade), each a move to another archetype, and each wakes the changes finalizers that watch those components. They are read only by render systems.

Measured with real components, 14,000 voxels, no finalizers or indexes (src/perftest/birth.ts in mecs):

birth per voxel
spawn, then three add stages ~1.7 µs
spawn with everything at once ~0.95 µs

So the three extra moves cost about 0.75 µs a voxel before any finalizer runs. Packing each group into one component removes two of the moves and 40 to 48 bytes of columns a voxel.

1. GPU accessors for struct components

accessorsOf (src/interface/gpu/accessors.ts) accepts only a scalar or a tuple of 2 to 4 same-typed scalars. A struct component, or a mixed tuple, is rejected ("isn't a scalar or a tuple of two to four scalars of one type"), although layoutOf already places structs for the storage rules. We can pack by hand into Vec4.U32 and unpack in WGSL, but the fields then have no names or types on either side.

Request: let an accessor name a struct component, either as a WGSL struct return or as one accessor per field (fn name_field(row) -> T), reading only the words of the fields used.

2. Packed bit fields: u64 and u128, and their cost

For the shade group (exposure 6 bits, occlusion 48, sunlight 30: 84 bits) and the look group, the natural representation is a few adjacent u32 words with bit fields. Please check, and state what holds today:

  1. Whether a U64 scalar (or a documented pair/quad of adjacent u32 lanes treated as a U128) can be declared, and how it reads and writes without BigInt in a row system, in a kernel: true system, and in the wasm kernel.
  2. The cost of a bit-field read-modify-write of one field of a 3×u32 component in a kernel row system, against the same field as its own U32 component. If the packed form is not about as fast, where does it lose (extra loads, a write-back of all lanes, change stamping of the whole component)?
  3. Whether a write to one lane of a tuple component stamps changed for the whole component (it seems to), and what that means for a GPU upload of a chunk when only one field changed.

3. Aside: command encoding

In a profile of a 14,000-voxel fall (add fallPosition, spawn voxels, despawn fallers) encodeValue/leafValue/element, the encoding of each command's JS value object into the command buffer, was the largest single line in the ECS's own time (~15 ms of ~176). A bulk path (spawnMany(archetype, count, fill), or per-column writes from a row system for components the entity already has) would avoid the per-entity object. Related: #259.

Happy to share the benchmarks and profiles.

主要言語
TypeScript
スター
12
フォーク
8
平均マージ
9時間 2分
マージ済み PR（30日）
25

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

adobe/data のほかの issue

adobe/data の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。