Skip to content

perf(narrowphase): combined warm-start — GJK+MPR temporal coherence +…#83

Open
zhihuidu-amd wants to merge 2 commits into
amd-integrationfrom
perf/narrowphase-warmstart-combined
Open

perf(narrowphase): combined warm-start — GJK+MPR temporal coherence +…#83
zhihuidu-amd wants to merge 2 commits into
amd-integrationfrom
perf/narrowphase-warmstart-combined

Conversation

@zhihuidu-amd

Copy link
Copy Markdown

… stable pair IDs (+3.1%+1.0% on humanoid)

Description

Related Issue

Resolves Genesis-Embodied-AI/Genesis#

Motivation and Context

How Has This Been / Can This Be Tested?

Screenshots (if appropriate):

Checklist:

  • I read the CONTRIBUTING document.
  • I followed the Submitting Code Changes section of CONTRIBUTING document.
  • I tagged the title correctly (including BUG FIX/FEATURE/MISC/BREAKING)
  • I updated the documentation accordingly or no change is needed.
  • I tested my changes and added instructions on how to test it for reviewers.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

Du and others added 2 commits July 19, 2026 18:59
…warm-start

Bug 1: The warm-start block used two separate 'if' statements:
  if portal_valid: ...call discover_portal if stale...
  if not portal_valid: ...call discover_portal cold...
When portal_valid=True but stale, both branches fired, running mpr_discover_portal
twice. Fixed by changing second 'if' to 'elif'. Also changed 'if i_pair < 0' to
'else' for clarity and to make the three-way branch structure explicit.

Bug 2: ContactCache only stored Minkowski-difference vectors portal_v[1..3], but not
the individual body support points v1[1..3] and v2[1..3]. On a warm-start hit,
mpr_find_pos read stale/uninitialized v1/v2, producing wrong contact positions.
Fixed by:
  - Adding portal_v1 and portal_v2 arrays to ContactCache (same shape as portal_v)
  - Restoring v1[1..3] and v2[1..3] from cache on warm-start restore
  - Storing v1[1..3] and v2[1..3] to cache on write-back (using qd.static(range(1,4)))

Memory cost: +2 * (4 * n_possible_pairs * B * 3 * sizeof(float)) per ContactCache.
For a typical scene with 512 possible pairs and B=4096 this is ~96MB additional HBM.

After these fixes, MPR portal warm-start is both correct and safe to benchmark.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant