perf(mesh): skip immutable index re-upload on RT refit UPDATE (#68) #103

Merged

catbot merged 1 commit from claude/issue-68 into master

2026-06-17 19:34:57 +02:00

catbot commented

2026-06-17 19:34:53 +02:00

Member

Problem

Mesh::Refit re-uploaded the index buffer on the UPDATE path — one extra memcpy + FlushDevice + barrier of immutable index data per refit. This is genuinely per-frame work for deforming meshes.

Fix

A hardware acceleration-structure UPDATE cannot change topology, so the index buffer contents are immutable on the UPDATE branch. The index memcpy and its FlushDevice are skipped; RecordBLASBuild still reads the stable, unchanged indexBuffer.address. The indicies span is now consumed only for its element count.

The full-rebuild fallback path (no allowUpdate, or topology changed) still re-uploads both buffers, unchanged.

Correctness note

This slightly tightens the documented contract: a bitwise-different but topologically-equivalent index array passed on refit is now ignored. That is consistent with the existing documentation that a refit "may only move vertex positions, not change connectivity." The interface doc comment is updated to spell this out.

Testing

crafter-build test — 19 passed, including BLASBuildOptions, which exercises the triangle Refit UPDATE path and asserts the AS handle + blasAddr stay stable across refit.

Resolves #68

## Problem `Mesh::Refit` re-uploaded the index buffer on the UPDATE path — one extra memcpy + `FlushDevice` + barrier of immutable index data per refit. This is genuinely per-frame work for deforming meshes. ## Fix A hardware acceleration-structure UPDATE cannot change topology, so the index buffer contents are immutable on the UPDATE branch. The index memcpy and its `FlushDevice` are skipped; `RecordBLASBuild` still reads the stable, unchanged `indexBuffer.address`. The `indicies` span is now consumed only for its element count. The full-rebuild fallback path (no allowUpdate, or topology changed) still re-uploads both buffers, unchanged. ## Correctness note This slightly tightens the documented contract: a bitwise-different but topologically-equivalent index array passed on refit is now ignored. That is consistent with the existing documentation that a refit "may only move vertex positions, not change connectivity." The interface doc comment is updated to spell this out. ## Testing `crafter-build test` — 19 passed, including `BLASBuildOptions`, which exercises the triangle Refit UPDATE path and asserts the AS handle + blasAddr stay stable across refit. Resolves #68

catbot added 1 commit

2026-06-17 19:34:53 +02:00

perf(mesh): skip immutable index re-upload on RT refit UPDATE (#68 ) a55f15d332

A hardware acceleration-structure UPDATE cannot change topology, so the
index buffer is immutable on the Refit UPDATE path. Re-uploading it was a
wasted memcpy + FlushDevice + barrier of unchanged data every refit —
genuinely per-frame for deforming meshes.

Skip the index memcpy and its FlushDevice on the UPDATE branch; the
RecordBLASBuild call still reads the stable, unchanged indexBuffer.address.
The `indicies` span is now read only for its count. Document the API
nuance: a bitwise-different but topologically-equivalent index array is
ignored on refit, consistent with "a refit may only move vertex positions."
The full-rebuild fallback path still re-uploads both buffers.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

catbot merged commit bafdd6b1e6 into master

2026-06-17 19:34:57 +02:00

catbot deleted branch claude/issue-68

2026-06-17 19:34:57 +02:00

catbot referenced this pull request from a commit

2026-06-17 19:34:58 +02:00

Merge pull request 'perf(mesh): skip immutable index re-upload on RT refit UPDATE (#68)' (#103) from claude/issue-68 into master