The DS GPU and its fun quirks

The DS &quot;GPU&quot; is indeed very bizarre and shares more in common with the GBA 2D rasterizer than a modern 3D GPU architecture. That it&#x27;s a scanline renderer that can handle quads directly should be a pretty big tell :)<p>I implemented a cheap subset of it used in Super Mario 64 DS for my online model viewer ( <a href="https:&#x2F;&#x2F;noclip.website&#x2F;#sm64ds&#x2F;44;-517.89,899.85,1300.08,0.37,-0.34,0.86,0.93,0.14,-0.34" rel="nofollow">https:&#x2F;&#x2F;noclip.website&#x2F;#sm64ds&#x2F;44;-517.89,899.85,1300.08,0.3...</a> ), but implementing all of the quirks and the weird featuresets might be nearly impossible to do in a modern graphics API. 2D rasterizers don&#x27;t have to be slow (as SwiftShader and ryg show), and you can get the bizarre conditions exactly correct. I&#x27;m not sure what a GPU-based implementation would even add.<p>EDIT: The math to be able to handle the bilinear quad interpolation on a GPU was worked out by reedbeta last year: <a href="http:&#x2F;&#x2F;reedbeta.com&#x2F;blog&#x2F;quadrilateral-interpolation-part-2&#x2F;" rel="nofollow">http:&#x2F;&#x2F;reedbeta.com&#x2F;blog&#x2F;quadrilateral-interpolation-part-2&#x2F;</a> . That&#x27;s a big roadblock gone, but there&#x27;s still a lot of other questionable things.

I wouldn&#x27;t even try emulating this properly with the standard GPU rasterizer, except as a fallback mode for underpowered systems. It would be fun to try using Image Load&#x2F;Store and Shader Storage Buffer Objects, though, in OpenGL 4.6. Just bind a framebuffer object with no color buffer and do all your writes using atomic operations to image objects and SSBOs in the fragment shader. The fragment shader interlock extension might be helpful if it&#x27;s available (note: it&#x27;s unavailable in Vulkan!) This is similar to how order-independent transparency or voxel rasterization works.<p>One possibility might be to do two passes: one to build up linked lists of per-fragment data (polygon ID, color, depth, etc.) and a second pass to sort all the linked lists into the proper order and determine a final color. This is the standard order-independent transparency trick.<p>You could build up tables as well--for instance, you could emulate the &quot;one span per scanline&#x2F;polygon&quot; behavior by allocating a table of scanlines for each polygon that you fill with the lowest X coordinate for that scanline and discard fragments that don&#x27;t belong to the triangle contributing the lowest such X coordinate.<p>I have no idea if this will actually work--if I had to guess I&#x27;d put a 50% probability on it not working out at all. The fallback would be a SIMD scanline renderer. The Image Load&#x2F;Store GPU implementation would be really fun though :)

At the time of its release, and the launch of certain titles like Metroid Prime: Hunters, and even Mario Kart DS, I was incredibly impressed with the DS’s graphics and performance considering its incredibly limited specs - 512kb texture cache and only 4MB of RAM. I understand it’s incredibly limited resolution and low-quality textures probably contributed to the ability to optimize the system and get such interesting performance out of it.<p>I truly enjoyed messing around with the home brew dev kits and loved putting my home made demos on my flash cart in high school, though I mostly stuck to 2D demos.<p>From what I understand, since the GPU is more akin to the GBA’s, and is a scanline-based renderer, does that mean it is more similar in its 3D architecture to, for instance, the Sega Saturn? (Incidentally, my other favourite system to write home brew for.)<p>The main differential, of course, it’s ability to display native triangles in addition to quads? (The Saturn literally did not have native 3D hardware as we understand it but literally drew thousands of scaled and transformed sprites as quads instead of the triangles we are used to today.)

I agree that Vulkan isn&#x27;t necessary, but neither is OpenGL, or a GPU at all. A software rasterizer would be the way to go. Even a mobile CPU should be able to rasterize 2048 polygons per frame at 256x192 using fixed point math. That&#x27;s almost Quake 1 levels of graphics, and Quake 1 was software rendered in 1996 on 75 Mhz Pentium 1s.<p>Edit: Reading other articles on the site, it seems like they started with a software renderer. I wonder why they decided to try OpenGL?

Makes me wonder if compute kernels would be a better solution if you&#x27;re trying to emulate all these rasterizer quirks while being fast enough to be playable.

DS being the Nintendo DS console GPU. Took me awhile to actually verify that&#x27;s what they were talking about, especially since it starts with paragraphs about Vulkan.