Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Finding the best sine function for Nintendo 64 [video]

youtube.com

Post reply on HN
Print view View original

21–30 of 47 posts

Re: Finding the best sine function for Nintendo 64 [video]

#21

Post by dietrichepp »

phire wrote: post #20
dietrichepp wrote: post #14

Earlier quoted context omitted.

Maybe that’s right, memory bandwidth is not the right explanation. But the rasterization itself is still often a big bottleneck, and maybe chalking it up to fill rate limitations is more explicatory. This is based on my limited observations writing my own N64 code and trying different scenes that put different amounts of load on the RDP—varying the load on the RDP was by far the easiest way to get framerate drops. If…

In one of Kaze's older videos [1] , he tracks both CPU and RCP time over various optimisations. The numbers make it pretty apparent that you can get significant RDP performance gains by reducing the amount of CPU bandwidth and/or improving it's access locality. The N64 is a unified memory system, and memory stalls triggered by the CPU will slow RDP down. The N64's memory controller appears to be very simple. As I und…

The bank organization is relatively well-known, so maybe you put the framebuffer in one bank, you put the zbuffer in another bank, and you have two banks left over without touching expansion memory. I mentioned World Driver Championship specifically because it runs at 640x480, and runs well, without the expansion pack.

Yes, memory access by the CPU will slow the RDP down. But the RDP is plenty slow even when the CPU is idle. The reason that we are seeing such improvements with SM64 is because SM64 was in such bad shape to begin with—something to be expected, given the novelty of 3D hardware in 1996 and problems with compiler bugs.

Re: Finding the best sine function for Nintendo 64 [video]

#22

Post by thebooktocome »

nsajko wrote: post #11

The video is very well produced and engaging, however (from skimming it), it seems that all the implementation methods it presents are suboptimal. The N64 CPU had an FPU, so it seems obvious that the best method, from both a speed and accuracy (or whichever is deemed more important) standpoint would be the same method that's used in all the libms in libcs like Glibc, musl or LLVM-libc, or in the standard libraries of…

By itself, Remez is not usually helpful for these kinds of low-accuracy polynomial approximations, because getting the minmax error beneath the quantization threshold is too strong a constraint. Usually one ends up doing some brute force polishing at the end to try and reduce the polynomial degree and/or the bits necessary to represent coefficients.

Re: Finding the best sine function for Nintendo 64 [video]

#24

Post by NovaDudely »

dietrichepp wrote: post #21
phire wrote: post #20

Earlier quoted context omitted.

In one of Kaze's older videos [1] , he tracks both CPU and RCP time over various optimisations. The numbers make it pretty apparent that you can get significant RDP performance gains by reducing the amount of CPU bandwidth and/or improving it's access locality. The N64 is a unified memory system, and memory stalls triggered by the CPU will slow RDP down. The N64's memory controller appears to be very simple. As I und…

The bank organization is relatively well-known, so maybe you put the framebuffer in one bank, you put the zbuffer in another bank, and you have two banks left over without touching expansion memory. I mentioned World Driver Championship specifically because it runs at 640x480, and runs well, without the expansion pack. Yes, memory access by the CPU will slow the RDP down. But the RDP is plenty slow even when the CPU…

Kaze explained once that a big part of performance issues was related to fill rate which I guess is part of the memory bandwidth issue. Essentially, polygon counts aren't a huge issue provided they don't use a large amount of screen space. While the Z-buffer will help out with larger polygons, it isn't a silver bullet solution.

That said, I don't doubt SM64 was in bad shape, this was really Nintendo's 1st attempt at doing 3D at that scale and almost everything was experimental. But even with that, it is amazing to see just how well a lot of it works despite this. But seeing some of the later stuff released on N64, it did seem like a really tapped out resource. Mind you looking at the Portal 64 coming along, it is neat to see that folks are still trying to push it just a little bit more.

Back to SM64, one thing I still find really cool is when you get Mario on a rotating platform, the rotation position and angle is calculated as it should be for both location and angle. That is just slick to see on something that old.

Re: Finding the best sine function for Nintendo 64 [video]

#25

Post by psychphysic »

abnercoimbre wrote: post #17

It's almost criminal Kaze isn't really welcome at most tech conferences because he plays fire with Nintendo's IP. A huge audience is missing out learning to do these things themselves, so my plug is we're running an indie conference [0] with Kaze as the featured speaker. We should follow in his footsteps. [0] https://handmadecities.com/boston

I find him a bit abrasive even though I enjoy his videos (and actually submitted this a couple days ago).

It's alot of cool work, but the way he presents it to laymen is kind of annoying. Even if he had never heard of data orientated design in the original video series (where he claims to not know what its called when you organise data to improve throughput) he should by now because clearly he does huge amounts of research. (Case in point at 9:30[0] he talks about localised memory patterns as though he's the first to come up with it).

Again, love his work, watch every video and even submit to HN because I think others would. But that doesn't mean he's not very annoying.

[0] https://youtu.be/xFKFoGiGlXQ?t=570

Re: Finding the best sine function for Nintendo 64 [video]

#26

Post by bruce343434 »

A lot of calculations and informed guesses and words like "could" "would" "should" but no benchmarks. Disappointing. With things like these, especially once you start to involve not-really-deterministic things like cache, you need to do integration testing of performance through benchmarks, not back-of-the-napkin calculations of how many instructions you are executing.

> Mario "could" walk in a different direction than he is pointing in

But did he? Was that a real, noticable problem or just theoretical?

Re: Finding the best sine function for Nintendo 64 [video]

#28

Post by smcl »

nstbayless wrote: post #5
dietrichepp wrote: post #4

Earlier quoted context omitted.

The question here is whether the new, optimized SM64 implementation is CPU-bound in the first place. Games on the N64 are often limited by memory bandwidth, which is taken up by rasterization, and SM64 was something of a special case—compiled with optimizations turned off due to GCC bugs. After recompiling with optimizations enabled, and maybe after swapping in newer versions of the RSP microcode, my guess is that fu…

One of the big optimizations Kaze makes is to remove a huge lookup table, which greatly reduces cache/memory usage.

That's kinda interesting - I imagine a lookup table was introduced as as an optimisation in the first place. I'm at work and I've had meetings so I haven't seen the linked video (or one of the ones where Kaze patched some functions in to get SM64 running at a constant 60fps) but I'm really keen to do so when meetings subside :) These little self-contained optimisation problems are really appealing, especially when someone smart has done something cool and innovative

Re: Finding the best sine function for Nintendo 64 [video]

#29

Post by contravariant »

If you're using a square root anyway it's also possible to only fit the part between 0 and pi/4, and use the square root to calculate the sine or cosine (whichever is greater).

However you need to be a bit careful that you return exactly sqrt(1/2) at pi/4 otherwise you get a discontinuity.

Re: Finding the best sine function for Nintendo 64 [video]

#30

Post by Snarwin »

psychphysic wrote: post #25
abnercoimbre wrote: post #17

It's almost criminal Kaze isn't really welcome at most tech conferences because he plays fire with Nintendo's IP. A huge audience is missing out learning to do these things themselves, so my plug is we're running an indie conference [0] with Kaze as the featured speaker. We should follow in his footsteps. [0] https://handmadecities.com/boston

I find him a bit abrasive even though I enjoy his videos (and actually submitted this a couple days ago). It's alot of cool work, but the way he presents it to laymen is kind of annoying. Even if he had never heard of data orientated design in the original video series (where he claims to not know what its called when you organise data to improve throughput) he should by now because clearly he does huge amounts of re…

> Case in point at 9:30[0] he talks about localised memory patterns as though he's the first to come up with it

This seems like an uncharitable interpretation to me. When he says "I'm not sure if anyone else has ever used this approach," it's pretty clear from context that the "approach" he's referring to is interleaving the sine and cosine tables to improve cache usage. And he doesn't even claim to be the first to come up with it, just to have independently discovered it.

Post reply on HN