Holy SHIT, I just figured out a way to directly HW accelerate Renderware's "decorated" Matrix type and eliminated the need for constant matrix format conversions in our Sega Dreamcast port of Grand Theft Auto 3! In the top-left is my modified version of the main RW matrix structure. It encoded a 4x3 matrix within the layout of a 4x4 matrix, where 3 elements of the final column were just left as uninitialized padding while the top element was used to encode metadata "flags" within the matrix. These flags were quite useful in that they encoded whether the matrices were in certain forms, allowing for various optimizations such as skipping transforms against an identity matrix or taking a fast path for an inverse... While this Frankenstein matrix format was fine with linear algebra routines being implemented in vanilla C, which can easily skip the padding and flags, it presented a real goddamn problem with HW accelerating the math via SIMD instructions. Now suddenly an intermediate conversion was necessary to go from the "decorated" matrix format to the "raw" matrix format, before it could be crammed into SIMD instructions... which was less than ideal. So... I came up with a crazy-ass idea that would allow me to DIRECTLY use the decorated matrices with the DC's SH4 CPU SIMD instructions... Since the SH4 instruction, FTRV (which can do a whole 4D vector transformed by a 4x4 matrix), is just an approximation, it turns out that at least a few of the least significant bits within the elements of the vector and matrix operands are simply ignored... which means... WE CAN SCOOT THE GODDAMN FLAGS TO THE END OF A FLOAT ELEMENT AND PASS THEM TO OUR SIMD INSTRUCTIONS WITH THEM GETTING SAFELY IGNORED! So now, as you can see on the right, we can replace the slow-ass C software routines with fast SH4-accelerated intrinsics which use the FTRV instruction, by simply changing the padding to proper identity matrix values plus abusing the 3 least significant bits of element [0][3] to store our flags! So now RW matrices are basically native DC 4x4 SIMD types... and we got some pretty handsome gainz (plus a few FPS in high FPS areas) to show for it!

Today's Grand Theft Auto 3 micro optimization for the Sega Dreamcast... speeding up vertex transformation by approximating perspective division. On the DC's SH4 CPU, a single-precision FDIV instruction takes a whole 13-14 cycles to execute. Ain't nobody got time for that shit, so we can abuse the builtin floating-point reciprocal square root approximation instruction (FSRRA) and a couple multiplications to perform a much faster, approximate division with an unsigned result ("MATH_Very_Fast_Invert()"). It turns out that for our PowerVR GPU, which requires clipping all polygons intersecting the camera's near Z plane, we never even need a negative result with a perspective divide, so this is an immediate win. You can see us using the "MATH_Very_Fast_Invert()" macro directly for the vertex submission routines on the right. For other scenarios where we'd like to be slightly better than a real FDIV, where we only need an approximate result, but we MUST preserve the sign of the value we're inverting, "MATH_Fast_Invert()" takes exactly as many cycles as an FDIV in isolation; however, other instructions can be get scheduled in with the routine when it gets inlined for better superscalar dual-dispatch utilization, plus the resulting value is able to be accessed by a later instruction in the pipeline earlier with this routine than with a full FDIV.

Been working on a ridiculously micro-optimized, HW accelerated, memcpy()-like routine to be used with our OpenGL driver on the Sega Dreamcast for quickly copying vertices and texture data around. On the left we have the main routine, fast_af_memcpy(), which will use the "Store Queues" on the DC's SH4 CPU to very quickly blast 32-byte (or cache-line sized) chunks of data around. If the source pointer is not 8-byte aligned, the slower (but still fast AF) path is taken, which simply repeatedly fills the SQs with the source data using 32-bit MOVs before flushing them to the destination address in an unrolled loop (with cache prefetches) written in C. If the source pointer IS 8-byte aligned, an SH4 assembly routine, sq_fast_cpy() is called, which swaps the DC's FPU to 64-bit double-precision load/store mode, filling and flushing the SQs with half as many MOV instructions, before swapping it back to single-precision upon completion. Finally, any remaining bytes that do not lie on block boundary are simply copied over using the standard memcpy().

I had the honor of getting to fly to Brussels to speak in the GCC Devroom at FOSDEM 2025 on behalf of the Sega Dreamcast homebrew community, talking about all of the amazing things we've done with the platform over this last year, powered by the latest and greatest version of the GCC toolchain! If you're interested in taking a casual stroll through C++20 timezone databases, C++26 concepts/constraints, low-level compiler optimizations, SH4 Assembly, OpenGL graphics with Ada, and much more, featuring Super Mario 64, Sonic Mania, Doom 64, and Grand Theft Auto 3, all running on the Sega Dreamcast... my talk is now live! fosdem.org/2025/schedule/eve…