This page describes the address range accessible from the ARM11, used to configure the basic GPU functionality. For information about the internal registers used for 3D rendering, see GPU/Internal Registers.

Address mappings for the external registers. GSPGPU:WriteHWRegs takes these addresses relative to 0x1EB00000.

Memory fills are used to initialize buffers in memory with a given value, similar to memset. A memory fill is triggered by setting bit0 in the control register. Doing so aborts any running memory fills on that filling unit. Upon completion, the hardware unsets bit0 and sets bit1 and fires interrupt PSC0.

Fragment lighting is a DMP extension to the standard OpenGL pipeline with which applications can calculate object lighting for each rendered pixel instead of just per vertex. The fragment lighting algorithm furthermore supports the shading models Blinn-Phong, Cook-Terrance, Ward, and microfacet-based BRDF-models. While the lighting calculations take place in a very localized position of the pixel processing pipeline, the feature interacts with different other pipeline stages.

In general, lighting is calculated at a particular point in space X by determining the angles (i.e. dot products) between different vectors:

GPU internal registers are written to through GPU commands. They are used to control the GPU’s behavior, that is to say tell it to draw stuff and how we want it drawn.

Each command is at least 8 bytes wide. The first word is the command parameter and the second word constitutes the command header. Optionally, more parameter words may follow (potentially including a padding word to align commands to multiples of 8 bytes).

This page collects some oddities and pitfalls of the PICA GPU which is used in the 3DS.

Vertex components which are defined through GPUREG_ATTRIBBUFFERi_CONFIG1 will be accessed aligned by the GPU.

• Vertex attributes will be aligned to their component element size.
• Padding attributes (Component type > 11) will always aligned to 4 byte offets into the buffer.
• The stride which is passed to the GPU should be passed unaligned.

The vertex stride set in GPUREG_ATTRIBBUFFERi_CONFIG2 must match the actual size of the vertex contained in the buffer or the PICA will freeze or it won’t draw anything.

Primitive Engine (PE) is one of the PICA200’s four vertex processor units and provides some unique features which are used to implement a geometry shader stage and variable-size primitive rendering.

The full functionality of PE is not yet understood and remains to be reverse-engineered.

Variable-size primitives are implemented by prefixing each per-primitive sequence of indices in an index array with a primitive size. This is used for various effects, for example Catmull-Clark subdivision and Loop subdivision. It is unknown how this feature is enabled specifically.

The 3DS GPU supports procedural generation of texture data using texture unit 3. Little is known about this feature, albeit a few public hints have been dropped. The contents of this page are solely based on reports on a 🔗 presentation given by DMP.

The related GPU registers can be found starting here.

Procedural texture generation has four stages:

• Noise Module (outputs u′,v′)
• Repeat Module (outputs u′′,v′′)
• Base Shape (also notated as G(u′′,v′′), output g)
• F(g) and Lookup Table

This stage applies noise on the input coordinates. Little is known about this other than that there are three noise parameters:

This page is intended to contain more higher-level explanation of concepts and features provided by the 3DS GPU. For more detailed register-level information check GPU/Internal Registers.

If a certain vertex attribute is constant for the duration of a draw call, instead of specifying a vertex array with repeated contents or changing the shader to use a uniform, fixed vertex attributes can be used. They let you specify a fixed value, which will be assumed by the attribute for all vertices of the batch.

A compiled shader binary is comprised of two parts : the main instruction sequence and the operand descriptor table. These are both sent to the GPU around the same time but using separate GPU Commands. Instructions (such as format 1 instruction) may reference operand descriptors. When such is the case, the operand descriptor ID is the offset, in words, of the descriptor within the table. Both instructions and descriptors are coded in little endian. Basic implementations of the following specification can be found at 🔗 1 and 🔗 2. The instruction set seems to have been heavily inspired by Microsoft’s vs_3_0 🔗 3 and the Direct3D shader code 🔗 4. Please note that this page is being written as the instruction set is reverse engineered; as such it may very well contain mistakes.