If the n64 had such a small texture cache then...
- Thread starter n64
- Start date
Intelligent swapping, small texture pieces heavily clamped, some surfaces flatshaded, and probably also a forced second pass or something like that... those are my 'likely candidates', anyway.
Conker's BFD had great textures too, but it came at a price in that case... (15-25 FPS average, I'd say).
Conker's BFD had great textures too, but it came at a price in that case... (15-25 FPS average, I'd say).
n64 said:
I didn't say BK did have a bad frame rate (pretty good for N64, actually)... reread my post. I only said that BFD has a bad frame rate.
And I doubt any more could've been done for BT... that was one of the last round of N64 games, period, and from Rare no less... I think if there was any more optimisation possible, it would've been done.
Same way anyone else would. No miracles I'm afraid.
4K just means no individual texture can exceed 4K and if your using Trilinear it's actually effectively 2K. Nothing stops you loading it over and over other than bandwidth.
Banjo does use 2 texture layers for a lot of the ground modulated with vertex alpha channels which does make it look a lot more varied than some other N64 titles.
My understanding is that Rare had micro code access well before anyone else. They used it for some custom lighting code, if I remember what I was told correctly, and in fact what I was told was accurate.
Megadrive1988
Veteran
One reason why I wanted the M2 so make it out was that it had 16k texture cache compared to N64's 4k. In addition to 8MB SDRAM.
what does XBox have in the NV2A?
what does XBox have in the NV2A?
What was playstations texture cache? or was it unlimited cause of Cds? & for some reason it didn't seem like DK64 had as good textures despite the fact it used the expansion pak, DK64 was really good at pushing polys, on the game when I zoom the camera out the Kongs look almost CG quality
M2's texture cache worked in the same fashion as the N64's in so far as it was explicitly loaded. I didn't suffer from the trilinear issue and yes it was 16K.
The problem with this type of cache is that it limits your maximum texture size and if it's small like the N64's it limits it to very small textures.
It's actually very small, but it doesn't matter because the whole texture doesn't need to be in it, same name "cache" different operation. It behaves more like the cache on a CPU, texels are cached into it so that they can be reused in filtering operations. How big the maximum texture can be isn't limited by the cache size.
The playstation textured from a large texture page, of which you could draw from a 256x256 sub-page. There was a cache of sorts used after the page, but it wasn't explicitly loaded basically if my memory serves me correctly if a row was >32 pixels there was a performance penalty.
The N64 expansion pack was just extra main RAM, nothing else. Despite what it said on the box it didn't improve AI, it didn't improve graphics performaance all it did was give you more space.
So were the Banjo games and BFD doing multi-texturing or did I misread the posts ?
The N64 would seem to have the fillrate for it but could it blend efficiently enough to make that possible - and could it do 2 textures in one pass (a must presumably given the relatively weak triangle rate?)
Did you effectively lose 2k of tmem even with just bilinear filtering? Could point sampling improve fillrate performance much?
Also, did the N64 have decent profiling tools like the performance analyzer that Sony bandied about all the time? (I understood it to be a special, sort of system level profiler but I'm not really up on this stuff.)
Sorry for all the questions but I find the utilization of older hardware really interesting
The N64 would seem to have the fillrate for it but could it blend efficiently enough to make that possible - and could it do 2 textures in one pass (a must presumably given the relatively weak triangle rate?)
Did you effectively lose 2k of tmem even with just bilinear filtering? Could point sampling improve fillrate performance much?
Also, did the N64 have decent profiling tools like the performance analyzer that Sony bandied about all the time? (I understood it to be a special, sort of system level profiler but I'm not really up on this stuff.)
Sorry for all the questions but I find the utilization of older hardware really interesting
I'm not comfortable getting into specifics on the NV2A cache, I know cache size is one of those pieces of info that IHV's like to keep quiet.
As for compressed textures, the texture is expanded as it's read from memory and stored in one of a number of formats in the cache. NV2A has a massive amount of read bandwidth from the cache so it's not really an issue. Compressed textures basically just increase the number of texels that can be read into the cache/cycle.
Banjo does, Ive never bothered playing BFD so I can't comment there.
In real terms N64's fillrate was comparable to that of PS it didn't really have a big advantage. Most N64 titles woluld either have been fill bound or more likely CPU bound. Cache size and RAM latency were such that unless data and code were extremly carefully organised CPU performance would be very poor.
No basically, Trilinear requires you to read from two different MIP levels simultaneously. In order to accomplish this you have to split the texture cache in half, and have one MIP level in each half, so you end up with the largest MIP level limited to 4K/2 = 2K.
Not really, but the performance analyzer wasn't available to the majority of PS developers until the end of the PS life span either.
Any decent developer puts there own profiler in place as they build the application. The difficult part is to understand what the results tell you, IMO most developers spend a lot of time optimising the wrong thing because they labour under misconceptions of how the hardware is interacting.
The same way we did. Towards the end of the N64 lifespan Nintendo released uCode tools and documentation to a few developers. Factor five were one of them.
Yes Basically.
In the case of a compressed texture basically it reads X bytes of data from main memory and writes Y (where Y>X) bytes into the cache. This minimises the read bandwidth at the cost of providing increases bandwidth from the cache.
The texturing logic then only has to deal with the limited number of texture formats that are actually supported inside the texture cache.
FWIW except in contrived cases the texture cache is extremely efficient.
Ah ok, so its still compressed as its being sent over the main mem bus and is then decompressed as its stored in the texture cache. So if the texture cache was say 128kb it could take 21kb of compressed data from main ram, transfer it over the main mem bus and decompress to the full 128kb (6:1 compression) of data into the texture cache. That's ok then, for a second I thought you mean it was decompressed before being sent over the mem bus to the NV2A. In which case it would have only helped main ram space and not bus bandwidth, which would have been a big flaw.
Thanks for clearing that up.
Oh BTW, I know you've also worked on GameCube so could you tell me this. Does Flipper work the same as NV2A as far as compressed textures and texture caches go? Or can the texture data be stored in a compressed format inside Flipper and only decompressed as needed for rendering?.. which is what I've heard.
NOTE: Please nobody think I'm trying to start a argument on which console it better here just on the basis of wether or not compressed textures can be stored in the texture cache. Because that's not my intention.
Thanks for clearing that up.
Oh BTW, I know you've also worked on GameCube so could you tell me this. Does Flipper work the same as NV2A as far as compressed textures and texture caches go? Or can the texture data be stored in a compressed format inside Flipper and only decompressed as needed for rendering?.. which is what I've heard.
NOTE: Please nobody think I'm trying to start a argument on which console it better here just on the basis of wether or not compressed textures can be stored in the texture cache. Because that's not my intention.
My understanding is that the Gamecube cache does indeed store compressed textures directly.
Gamecubes cache though provides a somewhat different function than the
one in NV2A, so they're not really directly comparable.
GC's cache is large and is really designed to hold all or at least most of the texture it's reading from locally. You can either explicitly load the cache with the texture (the most efficient method if you can schedule the loads ahead), or have it load the texture in pieces on demand. It demand loads in much larger blocks than NV2A and it's twiddled format is very different in order to exploit the different locality that occurs with a larger cache. Drawing two objects sharing the same texture will most likely cause the texture to move accross the bus only once.
The downside is the potentially for increased idle time for the pipelines when the texture is originally fetched. To be honest I didn't spend a huge amount of benchmarking GC so I have no idea if this is actually a significant impact.
NV2A has a VERY small cache, it's really just designed so that a texel doesn't have to be refetched when it's used multiple times rendering pixels on one tri or possibly a small group of tris with shared texture cooordinates. In most cases the result is that trilinear is no more expensive in terms of memory bandwidth than point sampling.
megadrive0088
Regular
my guess is, the NV2A cache is between 32k and 256k
yeah, a pretty wide range, but I'll bet it's within those amounts.
yeah, a pretty wide range, but I'll bet it's within those amounts.
DeathKnight
Regular
Supposedly it has the quadcache thingy present in the GF4. The cache itself is fairly small, but the bandwidth is pretty enormous (~30Gb/sec or so).
