Live data from Hacker News

The DS GPU and its fun quirks

melonds.kuribo64.net

11–20 of 25 posts

Re: The DS GPU and its fun quirks

#11
post #8
post #7

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.

It should be easy enough to upload the final rasterized texture to the GPU and apply filters there.

Re: The DS GPU and its fun quirks

#12
post #7

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 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

#13
post #5

The 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?

I want to! I have a few articles I've written in the pipeline, but it's always a struggle to find a topic to write about. I did write this article about a very specific effect though: http://blog.mecheye.net/2018/03/deconstructing-the-water-eff...

Re: The DS GPU and its fun quirks

#14
I 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 extension might be helpful if it's available (note: it's unavailable in Vulkan!) This is similar to how order-independent transparency or voxel rasterization works.

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.

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

#15

I 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

#16
post #15

I 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.

Well, compute shaders have the drawback that you have to know how many work items (in this case, fragments) you need to dispatch in advance. You can figure this out for triangles and quads, but it's a pain, and it basically involves doing the same thing the rasterization hardware already does in software. It's much simpler and faster to just use the rasterization hardware built in to GPUs to dispatch fragment work groups dynamically via a triangle draw call and only override the sample processing step.

Re: The DS GPU and its fun quirks

#17
post #12
post #7

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 increase the internal resolution to render at 4K or more, which I believe is much faster when using hardware to do it.

4K at 60 FPS is basically impossible on CPU.

Re: The DS GPU and its fun quirks

#18
post #12
post #7

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 increase the internal resolution to render at 4K or more, which I believe is much faster when using hardware to do it.

Wow, yeah, that would be a reason to use hardware. Here's what that looks like: https://youtu.be/tvGVqGQIDGA

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

#19
post #10
post #3

DS 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.

Ha! The domain is what gave it away for me as well. Perhaps the HN title could be made more clear?

Re: The DS GPU and its fun quirks

#20
post #11
post #8

Earlier 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.

That doesn't help when geometry is a target for shading.
Post reply on HN