Brian DegenhardtandClaude Fable 5
c25e1a58cc
VertexKickDirect round-tripped every hot buffer field through memory per
vertex: m_vertex/m_index pointer loads plus head/tail/next/xy_tail/itail
loads and stores each kick, all loop-carried through store-forwarding on
in-order cores. The MQ65 annotate put this bookkeeping at ~15% of the
handler (m_vertex reloaded 7x, m_index 4x per vertex).
Introduce VertexKickCursor: the fused packed handlers load
{vb,ib,vbuff,ibuff,head,tail,next,xy_tail,maxcount,itail} into locals
once per batch and pass the cursor through VertexKickDirect, so the
fields live in registers across the whole GIF batch. The cursor is
stored back before - and reloaded after - every callee that can flush,
grow or switch draw buffers (CheckOverlapVertsSlow + Flush,
HandleAutoFlush, GrowVertexBuffer, Flush(VERTEXCOUNT)); GrowVertexBuffer
in particular reads tail/itail for its preserved-copy sizes. The
env-backup block (memcpys + SetDrawBufferEnv) touches no buffer state
and rides through cursor-resident. The staged VertexKick wrapper keeps
piecemeal handlers at their previous load-once/store-once shape.
Also hoist the depth-clamp decision out of the per-vertex path:
GetDepthClampMode() resolves config + renderer kind + ZBUF bpp once per
batch (all invariant across a fused batch) and ApplyDepthClampMode
applies the resolved mode, replacing 3 GSConfig loads and a
GSIsHardwareRenderer() call per vertex with one register compare - which
also removes the only warm-path call from the loop CFG.
Verified: the built <4u,false> handler loads the cursor once at entry
and after the two flush seams only; stores appear only on the overlap
slow path; depth-clamp is two cmp/branch on the disabled default.
Gates: gs_vertex_tests 9/9; gsrunner frame hashes bit-identical to the
pre-campaign baseline for all 15 dumps on sw and vulkan;
GS_VERTEX_CROSSCHECK replay of all dumps clean; recompiler_tests
1359/1359.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
yaps2
This is a fork of PCSX2 targeting ARM based linux handheld devices. We're aiming to be performant and compatible on lower end ARM hardware, and adopt a "by any means" philosophy.
Thanks
A massive thank you to the PCSX2 team for 20 years of dedication. yaps2 doesn't meet the rigor required of PCSX2 upstream commits, but maybe someday it will.
The following people worked on the yaps2 fork of this project:
- bmdhacks
- tokyovigilante
- pstef
FAQ
Is it good?
A: Yeah. It's pretty fast.
Where do I get builds of this software?
A: Builds are available in nightly releases of Rocknix and Batocera
Did you vibe code it? I see that claude authors your commits you cheater!
A: This fork was written by seasoned developers using LLM devleopment tools. Our philosophy is focused on results, not policing methodology, and modern LLM tools are the most effective way for us to reach our goals.
Can I contribute?
A: Sure. Send a PR. If it's vibe-coded trash we'll reject it. If it's good we'll use it.
Can I fork this project for my own purposes?
A: Sure. If you do cool stuff we'll probably use your code.
Don't you know about XYZ project that already does this
A: Yes we probably copied a lot of their techniques.
Can I make feature requests or tell you that I don't like what you're doing or how you're doing it?
A: Look, we're not trying to be a serious project here so no.
Can I make bug reports?
A: Absolutely, file a github issue and we might look at it.