Some question about Xbox/GC hardware
- Thread starter Legion
- Start date
I have a question. I've always heard that the implementation of S3TC was more efficient on Flipper but I've never heard a clear explanation on why. Something about the GPU being able to access the texture in a compressed state, instead of having to decompress it first, then apply it to objects. Is that it?
The hardware only supports 24bit 6666 or 8880 and 16bit not 32 bit.
The 480p restriction is not really a function of the internal frame buffer, although that does restrict the usefullness of higher resolutions, it's a function of the TV interface. Guessing dince I don't have my devbox plugged in, even if the hardware supports >480P I doubt the libraries provide support for anything over 480P just because there is no practical way to output it.
The frame buffer is uncompressed, the Z Buffer is compressed losslessly upto 4:1. In practice 2:1 is more common, and there are pathological cases that will net worse results.
The embedded memory, and by enlarge a much better backend (pixel pusher). In T&L terms, IMO at least GF2 is superior, it's much closer to including most useful features.
It has an extra set of 4 Z units/pipe up front in the pipeline, so if you draw front to back, it can reject occluded pixels at 4x it's maximum fill rate. When coupled with the ZCompression it actually has a chance of getting near this rate.
Flipper allows the programmer to specify whether the Z unit is before or after texturing. When it is before then it can avoid the texturing step on occluded pixels, but only at it's maximum fill rate. The issue with this is that if the pixel is rejected based on the texture read (say 1 bit alpha sprites), you have to change Z unit modes, and loose the early reject.
The test is artificially trying to bias in favor of flipper by requiring 2 of the most complex geometry passes possible on NV2a. However, I still suspect
using NV2a's fixed function pipeline, and comparable lights (flipper has a somewhat odd lighting model), NV2a would still be faster.
However without specifying the actual blend modes it's really hard to tell, since this would dictate how the shader was split into passes and how much of the lighting needed to be done in both passes.
No it's not any more efficient. I assume this comes from the "Flipper stores textures compressed in it's cache and NV2A doesn't" argument. NV2A does decompress textures into the cache, but it never reads uncompressed textures over the main bus.
In almost all cases NV2A is just plain faster than flipper, it isn't really very surprising when you look at the relative costs of the boxes, along with the power and cooling requirements.
As I said in an earlier post. Flipper can store compressed textures in its texture cache and only decompress as its being worked on. NV2A decompresses a texture as its stored in the cache. Both Flipper and NV2A still take compressed textures over the main memory bus, so there's no difference there. The difference is just that while Flipper can make 6 times better use of its texture cache size and bandwidth (6mb effective size and 63gb/s effective bandwidth rather then 1mb real size and 10.5gb/s real bandwidth), NV2A can't. How important that is to performance is anyone's guess.
EDIT: Ah, I see ERP has already answered this.. that'll teach me for leaving this page unrefreshed for ages before replying
Ah I understand now, thank you.
Well call me crazy but that does sound like a more efficient setup. The S3TC itself is done the same way on both systems but the GC just extends its usage further. This would give Flipper the advantage when it comes to repeating textures wouldn't it?
It most likely wouldn't make a significant difference on the NV2A given the size of its cache (I heard it's 256K). Still, I don't understand the reason for this limitation. If the GPU is already set up to process compressed textures from main RAM, why not extend this to the cache?
As I've mentioned before you can't really compare the two texture caches, they perform different functions. The NV2A texture cache is designed to remove redundant reads incurred in texture filtering. The Flipper cache is designed to hold textures more like the EDRAM on the PS2. Flipper does support fetch on demand for textures (virtual texturing), but it's in very large blocks.
Flipper supports a relatively limited set of texture formats. NV2A supports many more, I assume the decompression during fetch is to simplify the number of different formats they have to deal with in the texturing logic. It could also be that their isn't a significant benefit to storing them compressed in the cache, given the massive amout of bandwidth available to read from the cache.
BTW you heard wrong, I think I've heard every possible number thrown out there on the NV2A texture cache size, very few people are even close.
G
Guest
Guest
Factor 5 have a new GC game that will graphically blow away all known GC games. 8)
G
Guest
Guest
Why should i?
It is widely known that F5 is doing an amazing GC game.
It is widely known that F5 is doing an amazing GC game.
Nonsense. Factor5 insists that the GC "can do everything the Xbox can do".
Seriously, for people like me who don't really have access to the information you guys have, it's statements like these (from F5) that throw us off. I don't doubt any of the things you said in this thread so I come to the conslusion that the statement was clearly false. If they really meant what they said then their new game should look just as good as Halo2. Oh I guess we'll see.
But I'd have to agree with Chap. Their new game will probably look the best on GC so far. After all the priliminary work, they only worked 9 months to produce Rogue leader which is arguably still one of the best looking game on the system. So with all the time they've had, their next game should look much better.
Similar threads
