I agree that Vulkan isn'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's almost Quake 1 levels of graphics, and Quake 1 was software rendered in 1996 on 75 Mhz Pentium 1s. Edit: Reading other articles on the site, it seems like they started with a software r…
People like to add shaders to their emulation these days; crt filters, colour adjustment, samplers, etc.
The DS GPU and its fun quirks
11–20 of 25 posts
Re: The DS GPU and its fun quirks
#12I agree that Vulkan isn'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's almost Quake 1 levels of graphics, and Quake 1 was software rendered in 1996 on 75 Mhz Pentium 1s. Edit: Reading other articles on the site, it seems like they started with a software r…
Re: The DS GPU and its fun quirks
#13The DS "GPU" is indeed very bizarre and shares more in common with the GBA 2D rasterizer than a modern 3D GPU architecture. That it's a scanline renderer that can handle quads directly should be a pretty big tell :) I implemented a cheap subset of it used in Super Mario 64 DS for my online model viewer ( https://noclip.website/#sm64ds/44;-517.89,899.85,1300.08,0.3... ), but implementing all of the quirks and the weir…
Wow, that site is absolutely amazing. Fun seeing the great sea all at once! Do you write/blog about working on that?
Re: The DS GPU and its fun quirks
#14One 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.
You could build up tables as well--for instance, you could emulate the "one span per scanline/polygon" 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't belong to the triangle contributing the lowest such X coordinate.
I have no idea if this will actually work--if I had to guess I'd put a 50% probability on it not working out at all. The fallback would be a SIMD scanline renderer. The Image Load/Store GPU implementation would be really fun though :)
Re: The DS GPU and its fun quirks
#15I wouldn'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/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 extens…
Re: The DS GPU and its fun quirks
#16I wouldn'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/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 extens…
I was thinking about actually going straight to compute shaders and forgoing the the normal GPU rendering pipeline completely. The quirks outlined in the article are such a big deviation from normal pipeline behavior that I don't know if it is worth trying to use that at all. Performance should be a no-brainer on any halfway modern system anyway.
Re: The DS GPU and its fun quirks
#17I agree that Vulkan isn'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's almost Quake 1 levels of graphics, and Quake 1 was software rendered in 1996 on 75 Mhz Pentium 1s. Edit: Reading other articles on the site, it seems like they started with a software r…
People like to increase the internal resolution to render at 4K or more, which I believe is much faster when using hardware to do it.
Re: The DS GPU and its fun quirks
#18I agree that Vulkan isn'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's almost Quake 1 levels of graphics, and Quake 1 was software rendered in 1996 on 75 Mhz Pentium 1s. Edit: Reading other articles on the site, it seems like they started with a software r…
People like to increase the internal resolution to render at 4K or more, which I believe is much faster when using hardware to do it.
Kind of an interesting aesthetic. It looks less terrible than I expected. I think it would be interesting to apply some of the recent machine learning based upsampling techniques on DS games too.
Re: The DS GPU and its fun quirks
#19DS being the Nintendo DS console GPU. Took me awhile to actually verify that's what they were talking about, especially since it starts with paragraphs about Vulkan.
I was wondering if it was in reference to the Nintendo system too, but then I read the domain.
Re: The DS GPU and its fun quirks
#20Earlier quoted context omitted.
People like to add shaders to their emulation these days; crt filters, colour adjustment, samplers, etc.
It should be easy enough to upload the final rasterized texture to the GPU and apply filters there.