The DS GPU and its fun quirks • Hacker News Board

Re: The DS GPU and its fun quirks

#21

Post by lostgame » Sun, Oct 28, 2018, 9:30 PM UTC

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.

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.

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

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

Re: The DS GPU and its fun quirks

#22

Post by gmueckl » Sun, Oct 28, 2018, 9:51 PM UTC

pcwalton wrote: post #16

gmueckl wrote: post #15

Earlier quoted context omitted.

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

You know that GPUs can dispatch work dynamically themselves to overcome this problem, right? So you totally can have one computation step determine how many instances it requires for the next one.

Re: The DS GPU and its fun quirks

#23

Post by pcwalton » Mon, Oct 29, 2018, 6:17 AM UTC

gmueckl wrote: post #22

pcwalton wrote: post #16

Earlier quoted context omitted.

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

You know that GPUs can dispatch work dynamically themselves to overcome this problem, right? So you totally can have one computation step determine how many instances it requires for the next one.

Yes, it's possible, but why bother when the hardware can rasterize triangles in silicon? :)

Re: The DS GPU and its fun quirks

#24

Post by vanderZwan » Mon, Oct 29, 2018, 10:53 AM UTC

Jasper_ wrote: 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…

> Let’s now define bilinear interpolation for a quadrilateral exactly the same way, except that instead of four texel colors, we’ll have the four vertices of the quad.

This sounds so ridiculously obvious when reading it that I would be surprised if nobody thought of working this out before. Or is the GPU code really difficult to work out compared to how simple the conceptual approach is?

> By the way, the fact that bilinear interpolation creates quadratic splines along diagonals can be exploited to evaluate splines in a GPU texture unit.

That also sounds very interesting!

Re: The DS GPU and its fun quirks

#25

Post by gmueckl » Mon, Oct 29, 2018, 2:56 PM UTC

pcwalton wrote: post #23

gmueckl wrote: post #22

Earlier quoted context omitted.

You know that GPUs can dispatch work dynamically themselves to overcome this problem, right? So you totally can have one computation step determine how many instances it requires for the next one.

Yes, it's possible, but why bother when the hardware can rasterize triangles in silicon? :)

Because it can't handle them in the prculiar fashion that was described? And it is worse for quads.