Conversation
fjtrujy
force-pushed
the
cmake
branch
3 times, most recently
from
adc93bd to
23025e6
Compare
fjtrujy
force-pushed
the
cmake
branch
2 times, most recently
from
36d1963 to
14ac514
Compare
The 12 sce_*_vcl.vsm files were generated by Sony's proprietary vcl tool from the matching vu1/*.vcl sources. They are committed here as the ground truth against which openvcl output is diffed by the upcoming regression harness. These artifacts are temporary. Once openvcl reaches functional parity with the proprietary pipeline (passing the regression harness for all 13 renderers), this commit should be dropped or squashed out via interactive rebase. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previously CMAKE_BUILD.md claimed only 11 of 13 renderers compiled with openvcl, listing `indexed` and `scei` as incompatible. Both now build cleanly with openvcl + masp, as confirmed by build-test/vu1/ containing all 13 .vo artifacts produced by the open pipeline. Also remove the commented-out skip block in CMakeLists.txt that used to fall back to pre-built objects for those two renderers. The fallback to pre-built .vo files via the outer if/elif/else for VU1 tools is preserved (still useful on hosts without the toolchain installed). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds cmake/vsm_diff.py plus CTest wiring that compares openvcl's output for each VU1 renderer against the matching Sony-generated reference in vu1/sce_<X>_vcl.vsm. The comparison is deliberately permissive about pipe pairing and register-allocator choices -- it checks: - opcode histogram (same mnemonics with same counts) - flag histogram ([E]/[I]/[D]/[T] occurrences) - label set (control-flow structure preserved) - non-nop slot count + ratio (rough scheduler-progress signal) The 12 renderers with a Sony reference get one CTest each, all labelled `vsm-diff` + `known-failing` and marked WILL_FAIL. Today every renderer diverges (openvcl produces 34-73% of Sony's instruction count because the dual-pipe scheduler and the multi-variant specialization aren't implemented yet), so WILL_FAIL keeps the build green; when a renderer starts matching, the test will XPASS so we notice. Baseline ratios captured at commit time: fast_nolights 0.72 general_pv_diff 0.37 fast 0.73 general_quad 0.34 general_nospec_quad 0.38 general_tri 0.38 general_nospec_tri 0.46 general 0.38 general_nospec 0.45 indexed 0.34 general_pv_diff_quad 0.39 general_pv_diff_tri 0.38 Usage: cmake -B build-test && cmake --build build-test ctest --test-dir build-test -L vsm-diff # raw diff for a single renderer: python3 cmake/vsm_diff.py vu1/sce_general_vcl.vsm build-test/vu1/general_vcl.vsm The scei renderer is skipped because the Sony reference for it uses a different naming convention (`scei_vcl.vsm` vs `sce_<X>_vcl.vsm`). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a build path that bypasses the .vcl -> .vsm half of the pipeline and assembles the in-tree Sony reference VSMs (vu1/sce_<X>_vcl.vsm) directly with dvp-as. Only dvp-as is required when this option is on; openvcl/masp/vcl/gasp are not consulted. Why: separates "openvcl produces wrong VSMs" from "ps2gl host-side bug unrelated to the VU1 microcode". Boot a sample built with this option ON and the same sample built with it OFF; if behavior diverges, the .vcl -> .vsm half is at fault. Empirical result (2026-05-11): lesson04 renders blank when built with openvcl, but renders the expected rotating triangle + quad when built with PS2GL_USE_SCE_VSM=ON. Confirms the rendering bug for samples that use glRotatef/glTranslatef lives in openvcl's VSM output, not in ps2gl's host code. Special-case: scei's reference VSM is named `scei_vcl.vsm` (no `sce_` prefix), so it gets a one-off path in the bypass branch. Usage: cmake -B build-sce -DPS2GL_USE_SCE_VSM=ON -DBUILD_EXAMPLES=ON cmake --build build-sce # boot build-sce/examples/<sample>.elf in PCSX2 to compare Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Cross-repo planning document covering ps2gl + openvcl + masp. Captures
the current state of the open-source pipeline migration, the open
items in priority order, and the commands needed to pick up where the
last session left off.
Key sections:
- §0 TL;DR -- the four open items and where to pick up.
- §2.1 The ps2gl GL_QUADS rendering bug (filed in openvcl/TODO and
repro committed at openvcl/test/repro/quad_adc_bug.vcl).
Workaround: this repo's `-DPS2GL_USE_SCE_VSM=ON` build option.
- §2.2 The dual-pipe scheduler (headline performance feature in
openvcl). Per-renderer baseline instruction-count ratios
captured.
- §3 What landed 2026-05-11 -- 14 commits across openvcl + ps2gl.
- §4 Sample-by-sample runtime-validation matrix.
- §6 Quick-reference commands for the full dev loop.
This file is intentionally cross-repo: pointing it from ps2gl is
practical because ps2gl is the integration target (the consumer of
both masp and openvcl). It's expected to be updated each session
as items get closed and new ones surface.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
§2.3 masp polish: the two FIXMEs in src/macro.c were inherited gasp doc-comments rather than bugs — rewritten as NOTE explanations in masp@b5de42a. The stale build_ps2/ directory was a leftover from a discarded PS2 cross-compile experiment and was removed. A new line items the dormant change_base trailing-`'` bug discovered while adding tests (only reachable via masp_syntax=0, i.e. gasp-compat mode; ps2gl runs masp_syntax=1). §2.4 test densification: masp went from 2 CTest entries to 5; new binaries test_sb (18 cases), test_hash (14 cases) and test_number_prefix (25 cases) land coverage on sb.c, hash.c, the is_base/sb_strtol/change_base/change_base2 family, and the modern 0b/0q/0h/0d numeric-prefix rewrites. openvcl-side coverage unchanged at 17 cases. TL;DR refreshed to point at the remaining masp work (README expand + change_base fix) and to record that the openvcl side is the next target for test densification. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
openvcl@edc5b76 added 25 tokenizer cases covering state/comments/ labels/mnemonic ID/fields/bit-flags. Refresh TL;DR and §2.4 to reflect the new count, swap "Tokenizer" line in the per-area table from open to ✅ with a follow-up line for the still-open argument-list parsing work (broadcast / indirect / post-inc / immediate operands). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
openvcl@acc1ba6 added 13 Parser-side cases covering one positive per VU operand family (FMAC, FDIV, LSU, IALU, BRU, RANDU, EFU) and four error-recovery negatives. Refresh TL;DR, the "infrastructure landed" bullet, and §2.4 to reflect the new total and mark the Parser row ✅. The Tokenizer argument-list row is bumped from "open" to "partial" because the Parser tests transitively cover broadcast (`MULw`), post-inc `(vi++)`, and `imm(vi)` addressing; pre-dec, `i`/`q`/`p`/`r` immediate operands, and indirect zero-form `(vi)` are still open. Adds a new openvcl TODO line at the end of §3: writing the family tests surfaced a latent error-propagation gap — the "Read-attempt from uninitialized float register" path prints to stderr but does not bump Error::m_errorCount, so openvcl exits 0 anyway. Sibling of the bug that commit 5c0227b fixed for CLIP. The Parser tests work around it by checking stderr substrings instead of exit_code on positives. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
openvcl@66b4486 routes the seven RegisterAllocator uninit-register- read paths through Error::Display, so they now bump m_errorCount and the process exits non-zero — mirroring the 5c0227b CLIP fix. Refresh TL;DR + "infrastructure landed" bullet for the +1 case (RegisterAllocator: uninit-read produces a non-zero exit, the regression-guard for the fix), and move the corresponding "open openvcl TODO" line under §3 from open to ✅ done with a pointer to both the commit and the guarding test. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
openvcl@520766b fixed the GL_QUADS rendering bug by correcting the CLIP operand template (drop ':write' on the first VF arg, which is a SOURCE not a DEST in hardware). openvcl@fd7cf6e added dual-pipe adjacent pairing as a side effect of the investigation. Update TL;DR to mark the bug fixed and the dual-pipe scheduler as partially landed. §2.1 keeps the original symptom + memory-dump table for historical reference under a new §2.1.1 heading; §2.1 itself is now the resolution summary. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds PS2GL_USE_SCE_VSM_FOR (semicolon-separated list of renderer names) which forces those specific renderers to assemble from Sony's reference VSM even when PS2GL_USE_SCE_VSM=OFF (the default open-source pipeline). Defaults to "general_quad" because of a residual openvcl bug in that specific shader: lesson04 / lesson05 render correctly (they route to the simpler general_pv_diff_quad shader), but box.elf enables specular lighting and routes to general_quad where the colors come out wrong such that the cube blends into the clear color and is invisible. Spliced Sony's general_quad VSM into an otherwise-openvcl build and confirmed box.elf renders the cube clearly — proving the bug is scoped to that one shader's emission, not a wider regression. This keeps the open-source pipeline as the default for 12 of 13 renderers while shipping a working box.elf today. Once openvcl's general_quad emission is fixed, the default for this option can drop back to an empty list. See memory/project_quad_bug_investigation_notes.md for the per-shader splice experiment and the full breadcrumbs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.