mirror of
https://github.com/flyinghead/flycast.git
synced 2026-11-08 17:12:25 -10:00
Joe Mattiello
907d15155e
0888 KRGB and 8888 ARGB, still went through the scalar per-pixel writer. One packed pixel is exactly one VRAM word, so they fit the same 8-word interleaved store as the 16-bit path, 8 pixels per iteration. The store is factored out of storeFramebuffer16Pixels() so both use it. 888 (24-bit packed) stays scalar: its pixels straddle VRAM words, so the store pattern only repeats every 4 pixels / 3 words. The address walk is the same as writeFramebufferLW(), so the output is identical to the scalar path, including when the padding isn't a multiple of 4. A harness writing 7,056 frames through both paths (both channel orders, modes 4 to 6, 6 frame sizes, 7 destination addresses including bank and VRAM edges, 7 line strides, 4 clip windows) gives byte-identical VRAM. The same algorithm measured about 2x faster on a 640x480 8888 frame (0.213 ms to 0.105 ms) on Apple Silicon. tests/src/rend/FramebufferWriteTest.cpp checks both 32-bit modes against an independent reference (one pvr_write32p per pixel, the scalar walk) over 3,600 cases: widths around the 8-pixel vector width, padding including values that aren't a multiple of 4, destinations at the 32-bit bank boundary and the end of VRAM, and clip windows, for both channel orders. All of VRAM is compared, so a store past the frame fails too. On arm64 it exercises the NEON path; elsewhere the scalar one. It fails when the padding computation is deliberately broken. Other architectures are unchanged. Co-authored-by: Claude Opus 5.5 <[email protected]> [ci skip]