4 ms·

I do wonder what would have happened if the N64 had included a much bigger texture cache. It seemed the tiny size was it biggest con.

rightbyte 3y ago
Wasn't the thing you put in the slot infront of the cart a ram extension slot? I think you can play Rogue Squadron with and without if you want to compare. Or do youe mean some lower cache level?
- skhr0680 3y ago
  that pack added 4MB extra RAM, OOT and Majora’s Mask are like night and day thanks to it. The N64 had mere kilobytes of texture cache, AFAIK the solution was to stream textures, but it took awhile for developers to figure that out
  - VelesDude 3y ago
    N64 had a 4KB texture cache while the Ps1 had a 2KB cache. But the N64's mip-mapping requirement meant that it essentially had 2KB + lower resolution maps. The streaming helped it a lot but I think the cost of larger carts was a big drag on what developers could do. It is one thing to stream textures but if you cannot afford the cart size in the first place it becomes merely academic.
    - skhr0680 3y ago
      I don’t think storage space was an issue for graphics in particular. Remember the base system had 4MB memory and 320x240 resolution
    - pezezin 3y ago
      The real problem was different. The PS1 cache was a real cache, managed transparently by the hardware. Textures could take the full 1 MB of VRAM (minus the framebuffer, of course). In contrast, the N64 had a 4 kB texture RAM. That's it, all your textures for the current mesh had to fit in just 4 kB. If you wanted bigger textures, you had to come up with all sort of programming tricks.
mrguyorama 3y ago
The other big problem with the N64 was that the RAM had such high latency that it completely undid any benefit from the supposedly higher bandwidth that RDRAM had and the console was constantly memory starved. The RDP could rasterize hundreds of thousands of triangles a second but as soon as you put any texture or shading on them, the memory accesses slowed you right down. UMA plus high latency memory was the wrong move. In fact, in many situations you can "de-optimize" the rendering to draw and redraw more, as long as it uses less memory bandwidth, and end up with a higher FPS in your game.
- mips_r4300i 3y ago
  That's mostly correct. It is as you say, except that shading and texturing come for free. You may be thinking of Playstation where you do indeed get decreased fillrate when texturing is on. Now, if you enable 2cycle mode, the pipeline will recycle the pixel value back into the pipeline for a second stage, which is used for 2 texture lookups per pixel and some other blending options. Otherwise, the RDP is always outputting 1 pixel per clock at 62.5 mhz. (Though it will be frequently interrupted because of ram contention) There are faster drawing modes but they are for drawing rectangles, not triangles. It's been a long time since I've done benchmarks on the pipeline though. You're exactly right that the UMA plus high latency murders it. It really does. Enable zbuffer? Now the poor RDP is thrashing read modify writes and you only get 8 pixel chunks at a time. Span caching is minimal. Simply using zbuf will torpedo your effective full rate by 20 to 40 percent. That's why stuff I wrote for it avoided using the zbuffer whenever possible. The other bandwidth hog was enable anti aliasing. AA processing happened in 2 places: first in the triangle drawing pipeline, for inside polygon edges. Secondly, in the VI when the framebuffer gets displayed, it will apply smoothing to the exterior polygon edges based on coverage information stored in the pixels extra bits. On average, you get a roughly 15 to 20 percent fillrate boost by turning both those off. If you run only at lowres, it's a bit less since more of your tender time is occupied by triangle setup.
  - mrguyorama 3y ago
    I was misremembering about instances involving the zbuffer and significant overdraw as demonstrated by Kaze https://www.youtube.com/watch?v=GC_jLsxZ7nw https://www.youtube.com/watch?v=GC_jLsxZ7nw Another example from that video was changing a trig function from a lookup table to an evaluated approximation improved performance because it uses less memory bandwidth. Was the zbuffer in main memory? Ooof What's interesting to me is that even Kaze's optimized stuff is around 8k triangles per frame at 30fps. The "accurate" microcode Nintendo shipped claimed about 100k triangles per second. Was that ever achieved, even in a tech demo?

rightbyte 3y ago

Wasn't the thing you put in the slot infront of the cart a ram extension slot? I think you can play Rogue Squadron with and without if you want to compare. Or do youe mean some lower cache level?

skhr0680 3y ago
that pack added 4MB extra RAM, OOT and Majora’s Mask are like night and day thanks to it. The N64 had mere kilobytes of texture cache, AFAIK the solution was to stream textures, but it took awhile for developers to figure that out
- VelesDude 3y ago
  N64 had a 4KB texture cache while the Ps1 had a 2KB cache. But the N64's mip-mapping requirement meant that it essentially had 2KB + lower resolution maps. The streaming helped it a lot but I think the cost of larger carts was a big drag on what developers could do. It is one thing to stream textures but if you cannot afford the cart size in the first place it becomes merely academic.
  - skhr0680 3y ago
    I don’t think storage space was an issue for graphics in particular. Remember the base system had 4MB memory and 320x240 resolution
  - pezezin 3y ago
    The real problem was different. The PS1 cache was a real cache, managed transparently by the hardware. Textures could take the full 1 MB of VRAM (minus the framebuffer, of course). In contrast, the N64 had a 4 kB texture RAM. That's it, all your textures for the current mesh had to fit in just 4 kB. If you wanted bigger textures, you had to come up with all sort of programming tricks.

mrguyorama 3y ago

The other big problem with the N64 was that the RAM had such high latency that it completely undid any benefit from the supposedly higher bandwidth that RDRAM had and the console was constantly memory starved. The RDP could rasterize hundreds of thousands of triangles a second but as soon as you put any texture or shading on them, the memory accesses slowed you right down. UMA plus high latency memory was the wrong move. In fact, in many situations you can "de-optimize" the rendering to draw and redraw more, as long as it uses less memory bandwidth, and end up with a higher FPS in your game.

mips_r4300i 3y ago
That's mostly correct. It is as you say, except that shading and texturing come for free. You may be thinking of Playstation where you do indeed get decreased fillrate when texturing is on. Now, if you enable 2cycle mode, the pipeline will recycle the pixel value back into the pipeline for a second stage, which is used for 2 texture lookups per pixel and some other blending options. Otherwise, the RDP is always outputting 1 pixel per clock at 62.5 mhz. (Though it will be frequently interrupted because of ram contention) There are faster drawing modes but they are for drawing rectangles, not triangles. It's been a long time since I've done benchmarks on the pipeline though. You're exactly right that the UMA plus high latency murders it. It really does. Enable zbuffer? Now the poor RDP is thrashing read modify writes and you only get 8 pixel chunks at a time. Span caching is minimal. Simply using zbuf will torpedo your effective full rate by 20 to 40 percent. That's why stuff I wrote for it avoided using the zbuffer whenever possible. The other bandwidth hog was enable anti aliasing. AA processing happened in 2 places: first in the triangle drawing pipeline, for inside polygon edges. Secondly, in the VI when the framebuffer gets displayed, it will apply smoothing to the exterior polygon edges based on coverage information stored in the pixels extra bits. On average, you get a roughly 15 to 20 percent fillrate boost by turning both those off. If you run only at lowres, it's a bit less since more of your tender time is occupied by triangle setup.
- mrguyorama 3y ago
  I was misremembering about instances involving the zbuffer and significant overdraw as demonstrated by Kaze https://www.youtube.com/watch?v=GC_jLsxZ7nw https://www.youtube.com/watch?v=GC_jLsxZ7nw Another example from that video was changing a trig function from a lookup table to an evaluated approximation improved performance because it uses less memory bandwidth. Was the zbuffer in main memory? Ooof What's interesting to me is that even Kaze's optimized stuff is around 8k triangles per frame at 30fps. The "accurate" microcode Nintendo shipped claimed about 100k triangles per second. Was that ever achieved, even in a tech demo?