FAQ: Difference between revisions

Line 24:

The tests Mazamars312 conducted are currently not reproducible with open source source and tools. Libdragon is planning to eventually release an open source IPL3, at which point it would be easier for others to experiment with the RDRAM initialization sequence.

=== Is it true that the RSP has hardware MPEG-1 acceleration? Is it used by Resident Evil 2 full motion videos? ===

'''Short answer:''' RSP has two couples of opcodes (<code>VMULQ</code>/<code>VMACQ</code> and <code>VRNDN</code>/<code>VRNDP</code>) that are meant to simplify implementation of a very small part of the MPEG-1 decoder (inverse quantization and oddification of IDCT coefficients). They are not used by Resident Evil 2 or any other commercial game though.

RSP is the vector coprocessor in Nintendo 64. It is well designed to also accelerate video codecs such as those of the MPEG family. To do so, though, careful assembly code must be written using the specific RSP vector opcodes to perform the various operations required for a video decoder. When RSP was designed by SGI (in the early 90s), only MPEG1 existed as a finished standard (MPEG2 was finalized in 1994, after the RSP design was frozen), so SGI designers decided to add a couple of opcodes to the instruction set to help implementing a part of the MPEG1 decoder: specifically, the algorithm that performs inverse quantization and oddificaton of IDCT coefficients. This is actually a quite specific part of the whole pipeline, and it is not even the most resource intensive one. It is hard to guess why the SGI designers thought it was important to specifically add these instructions or speed up this specific part of the pipeline.

Resident Evil 2, which is a marvelous example of careful code crafting, did manage to cram full motion videos together with the whole game in the limited 64 MiB cartridge. To do so, they encoded them with MPEG1 at a low resolution, bitrate and frame rate (around 15 fps), and then performed a nice interpolation (cross-fade) between frames using RDP. The MPEG decoder was not specifically accelerated though (if not for the final YUV to RGB conversion, which is technically not even part of MPEG): they simply recompiled a C player that worked good enough at that bitrate, so they did not get to use the special RSP instructions for it.

In modern times, libdragon provides a fully accelerated MPEG decoder that uses RSP and also [https://github.com/DragonMinded/libdragon/blob/afc35325e33d2bd3a73a01405aa5ecf1b367c5a9/src/video/rsp_mpeg1.S#L342-L343 uses the special RSP instructions]. This can also be used as further proof that the instructions SGI designed were indeed useful for their goal, albeit for a very small part of the whole algorithm.

@@ Line 24: / Line 24: @@
 The tests Mazamars312 conducted are currently not reproducible with open source source and tools. Libdragon is planning to eventually release an open source IPL3, at which point it would be easier for others to experiment with the RDRAM initialization sequence.
+=== Is it true that the RSP has hardware MPEG-1 acceleration? Is it used by Resident Evil 2 full motion videos? ===
+'''Short answer:''' RSP has two couples of opcodes (<code>VMULQ</code>/<code>VMACQ</code> and <code>VRNDN</code>/<code>VRNDP</code>) that are meant to simplify implementation of a very small part of the MPEG-1 decoder (inverse quantization and oddification of IDCT coefficients). They are not used by Resident Evil 2 or any other commercial game though.
+RSP is the vector coprocessor in Nintendo 64. It is well designed to also accelerate video codecs such as those of the MPEG family. To do so, though, careful assembly code must be written using the specific RSP vector opcodes to perform the various operations required for a video decoder. When RSP was designed by SGI (in the early 90s), only MPEG1 existed as a finished standard (MPEG2 was finalized in 1994, after the RSP design was frozen), so SGI designers decided to add a couple of opcodes to the instruction set to help implementing a part of the MPEG1 decoder: specifically, the algorithm that performs inverse quantization and oddificaton of IDCT coefficients. This is actually a quite specific part of the whole pipeline, and it is not even the most resource intensive one. It is hard to guess why the SGI designers thought it was important to specifically add these instructions or speed up this specific part of the pipeline.
+Resident Evil 2, which is a marvelous example of careful code crafting, did manage to cram full motion videos together with the whole game in the limited 64 MiB cartridge. To do so, they encoded them with MPEG1 at a low resolution, bitrate and frame rate (around 15 fps), and then performed a nice interpolation (cross-fade) between frames using RDP. The MPEG decoder was not specifically accelerated though (if not for the final YUV to RGB conversion, which is technically not even part of MPEG): they simply recompiled a C player that worked good enough at that bitrate, so they did not get to use the special RSP instructions for it.
+In modern times, libdragon provides a fully accelerated MPEG decoder that uses RSP and also [https://github.com/DragonMinded/libdragon/blob/afc35325e33d2bd3a73a01405aa5ecf1b367c5a9/src/video/rsp_mpeg1.S#L342-L343 uses the special RSP instructions]. This can also be used as further proof that the instructions SGI designed were indeed useful for their goal, albeit for a very small part of the whole algorithm.

FAQ: Difference between revisions

Navigation menu

Search