Add markdown for Schur/matrix-free memory performance in /doc#40
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a detailed documentation file, doc/memory_performance.md, explaining the GPU-memory performance benefits of using Schur complement and matrix-free optimizers in the bae package. The review feedback highlights several opportunities to improve the accuracy and completeness of this documentation. Specifically, the reviewer recommends updating the parameter formula to account for optimized intrinsics, correcting the reject parameter value to match the reference script, adding the missing benchmark script path, and fixing the formatting of the conditions table.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
|
||
| | Metric | Meaning | | ||
| | --- | --- | | ||
| | Number of parameters | The count of optimizable parameters: 3 per 3D point (xyz position) plus 7 per camera — i.e. 3 × (number of 3D points) + 7 × (number of cameras) | |
There was a problem hiding this comment.
In the description of the Number of parameters metric, it states:
3 per 3D point (xyz position) plus 7 per camera — i.e. 3 × (number of 3D points) + 7 × (number of cameras)
However, the benchmark is configured with OPTIMIZE_INTRINSICS = True (as mentioned in line 101), which means there are 10 camera parameters per camera (7 for pose + 3 for intrinsics).
Please update this formula to reflect the actual 10 parameters per camera used in the benchmark, or make it general to cover both cases (e.g., 7 or 10 parameters depending on whether intrinsics are optimized).
There was a problem hiding this comment.
@SEOKWOOPARK This needs to be resolved. We should optimize intr in all experiments.
There was a problem hiding this comment.
I changed all points from '7 camera parameters' to '10 camera parameters'.
…nding markdown and the graph image
| @@ -0,0 +1,159 @@ | |||
| # Improvement by Schur and Matrix-Free | |||
|
|
|||
| GPU-memory benchmark sweep for `bae`'s Bundle Adjustment optimizers. It runs a | |||
There was a problem hiding this comment.
Need to be specific here. What are "Bundle Adjustment optimizers"
Also need to provide more context before begining with benchmark sweep. Reader's won't understand what benchmark sweep is for without any context.
|
|
||
| GPU-memory benchmark sweep for `bae`'s Bundle Adjustment optimizers. It runs a | ||
| set of [BAL](https://grail.cs.washington.edu/projects/bal/) problems through | ||
| several optimizer configurations, records peak and average GPU memory, and plots |
There was a problem hiding this comment.
Readers won't understand what are "several optimizer configurations"
| and intrinsics together with 3D point positions to minimize reprojection error. | ||
| As scenes scale to millions of parameters, GPU | ||
| memory becomes the bottleneck, and how that linear system is | ||
| solved largely decides how much memory is used. |
There was a problem hiding this comment.
There is no need to explain BA.
There was a problem hiding this comment.
I deleted it. BA's meaning can be described in the main page of repo.
| @@ -1,9 +1,25 @@ | |||
| # Comparing GPU Memory: Schur, Matrix-Free, and LM | |||
There was a problem hiding this comment.
Comparing GPU Memory: Vanilla LM, Schur-complement Optimizer, and Matrix-free options
There was a problem hiding this comment.
Thanks for suggesting a more detail title.
2 participants
I added doc/memory_performance.md with a GPU-memory benchmark of bae's optimizers across three configurations: LM (matrix-free), Schur (normal), and Schur (matrix-free).
The PR explains the Schur complement and the matrix_free_normal path. It also shows that Schur + matrix-free cuts peak GPU memory by ~43% versus the LM baseline on the largest problem (venice with 3.0 M parameters). This change is documentation only.