R350/NV35 Z Fillrate with FSAA

I did some testing using zeckensacks incredible synthetic benchmark.

Here is a quote of the description of the tests i used with a Ti-4400 / 44.03:

~900 zixels/s for 4X MSAA means ~3600 written subzixels /s, which means about 13 written 16bit subzixels / clock. Not that far away from the 16.

 

So 4x AA is "free" on NV25, at least with 16 bit rendering. I dont know, if a 32-bit-ROP can be splitted into 2 16-Bit-ROPs, or if the bandwith the only limiting factor with 32 bit rendering. NV30 can calculate 8 "zexels" per clock, the chip got 16 ROPs, 2x AA is also "free".

NV25 can only calculate 4 z-only-pixels, with 2x or 4x there is no new serious drop, at least with 16 bit rendering. With textured Pixels, NV30's 4x AA is "essentially" free as far as i know.

 

2x AA isn't even free at 16-bit color, in fact it's slower than 32-bit.

From Dave's post:

Code:

FFP - Pure fillrate         1772.39  1743.24  1686.74   878.64 
FFP - Z pixel rate          3373.76  3148.66  1652.25  1571.46 
FFP - Single texture        1666.31  1203.08  1097.91   734.83 

Fillrate free, maybe, but not free. Remember, Z rejection rate is important with and without texturing.

 

With 45.23, nV disabled Early Z Occlusion for NV25 at least in D3D. Anyway, it was never enabled by default, afaik.

 

How much memory is it? Even redundant, if it's small it's small. Besides, we're looking at 64MB per chip, which even per chip would stay fantastic for some time.

GeForce3's bandwidth savings weren't that insanely great. What, +20%-30% efficency over GeForce2?

Well excuuuuuuuuse me, I'm just referring to the fact that NV3x has shown off some hellishly fast scores in 3DMark fixed function TCL texts, especially multiple lights, despite being about on par with R3x0 in vertex shaders.

o...k...

My mistake, I feel stupid now, having previously OWNED a K2.

All the games I tried at 1024 + 4x weren't particularly playable though, even to my standards. And I couldn't even play Quake3, half the textures were replaced with placeholders, looked like a Star Trek TNG holodeck. Works great on my Radeon though. Mrr. Anyway, 4x at 1024 wasn't playable on my K2. Period.

I was referring to REAL AF that time. i.e. Taking more real samples of the textures. Almost identical to GeForce3's implementation.

There's more aggregate texture bandwidth available, each TMU can fetch a trilinear sample every clock cycle, intelligent texture cache with recursive texturing... 8)

Wild imaginations = good for engineering.

Buh? It was said earlier that only P10 and Parhelia have true 256-bit memory.

 

[quote="Tagrineth]Buh? It was said earlier that only P10 and Parhelia have true 256-bit memory.[/quote]
And no one agrees with you.

 

That doesn't mean that Spectre wouldn't have been in an even better position with an advanced bandwidth saving technique on. Who knows there might not have been even the need for a multichip config after all hm? Did you see still the need for multichip configs in Fear, and if yes why not?

While 4xAA on the V5 especially in q3a was playable or what? Playable or not, it doesn't change the fact that in 32bpp the K2 managed roughly to yield similar performance as two chips on the V5.

And? That's one theoretical advantage, while NV20 held it's own theoretical advantages against it too. Only difference being that NV20's real time numbers are extensively known and you've nothing else but theory to base anything on.

We're both not engineers last time I checked. And 3dfx's "wild imagination" stopped at the V5 as in real products.

 

Hmm...

It seems to me that it can fairly be said that the Parhelia and R3xx cores are "256-bit chips", and that the associated highest spec products have "256-bit buses".

It also seems to me that two 128-bit chips can be said to be operating "as a 256-bit bus" if the 128-bit datapaths are utilized without effective redundancy in some type of data transfer. However, it can also said that there is not a "256-bit bus" with the associated challenges of trace layout to terminate all the paths for the 256-bits at the same place at one "end" for this instance.

AFAICS, a lot of this discussion is a dispute over people meaning different things from the above, when there are several valid ways of looking at things. Of course, correct me if I'm wrong.

 

I wouldn't say that it needs any corrections.

 

Feh, what is this, the Attack Tagrineth thread?

I didn't say that. I said "IT WAS SAID", not "I said".

And I agree on the semantics comment.

Of course, Spectre would've benefitted greatly from more bandwidth savings. Anything would =)

And I think... after Rampage, multichip would of course be helpful and offer horrifying speed advantages, but I don't know if it would've been necessary anymore. It all depends, maybe nVidia would've been more aggressive with NV25 had Rampage appeared, resulting in 3dfx deciding to go ahead with dual-Fear? It all depends on how much performance 3dfx needed, and how much they got out of one chip. Personally, though, I believe that Fear would've been faster than GF4Ti as we know it, in single chip, and 3dfx probably would've passed on dual if that was the case.

Of course. K2 is also a deferred renderer, though, while V5 is a very solid example of pure brute force. =) AFAIK V5 has few to no bandwidth savings of any kind. Oh, and yes, 4x AA at 800x600 in Q3A is totally playable on a V5.

Yeah, that's true enough. I suppose in practice, anything could've happened. There's also one more questionable element that we should consider, 3dfx's retarded-toward-the-end driver department... I wonder if they could've pulled their collective heads out of their asses in time to make a workable Rampage driver?

True, but we're discussing engineering stuff and I said that in terms of 3dfx's designing the feature and possibly using it.

 

Considering the prices and availability of ram (always hypothetical) of the projected period for release, I doubt it would have been clocked higher than 250-275MHz.

In terms of dx7 applications alone, I don´t believe that even a Kyro3 at 250MHz would have been able to outperform a Ti4600. With a respin for 300MHz (since it was on 13nm) probably yes. Those prototypes do exist, but it´s more likely that a ImgTec employee will sell his mother to you, than give you anything reliable on it.

Two choices: either release it with a completely bug-fested driver or delay.

What that HSR thingy? It was a dumb idea since the very beginning. If it would have been such a smart idea I don´t see a single reason why NVIDIA wouldn´t have made use of it, along with all the other tidbits that made it into NV25 and past that, since the gentleman who originally fooled around with it, works actually there from 3dfx´s demise.

 

Why wouldn't a K3 beat a Ti4600? K2 at 175MHz was about level with GF2 GTS, sometimes even approaching the Ultra... that's two pipelines with SDR versus 4 pipelines with 2 TMU's each with DDR, all at a higher clock speed.

Not necessarily, now that I think about it. The awful state of V5's driver could've been caused by focusing more on preparing Rampage's driver. But now we're getting to the "Baseless Speculation" point and I don't see a point in continuing this issue...

Simple, that HSR thingy could only get rid of ~30-50% tops, and that with a small visual error... any more removal and you get massive problems. People with V5's have -proved- that with relatively simple tweaking you can get no visible error and still gain significant performance with the feature as implemented in the 1.04.01 beta. nVidia never used it because I get the feeling GF3's Early Z Reject has similar removal without the errors.

 

Because you're way too optimistic with vaporware and that's what this whole debate is about. The K2 was a GF2MX competitor, embarassing higher GF2 models under occassions, yet apart from the MX it wasn't outperforming anything else overall. 1 TMU per pipe by the way.

a) Early Z works ideally in first Z-pass only applications. That's not the only point where NV2x's gain in performance, the combination of them all is what really makes the difference. Similar removal on NV2x? ROFL ok anything you say....

b) We're talking about an illegitimate method to drop geometry here. It hasn't puzzled you one bit why let's say PowerVR hasn't resulted all these years to similar stupidity, when they have full hardware order independant HSR? Or does it escape your memory that the humble KYRO has a total of 32Z units?

c) Yes the "tweak" would be to cap the framerate at 60fps maximum and that's what the idea was all about. When we can maintain 60Hz and the rendering takes too long, let's drop some geometry. In other words let's just violate the games BSP, because we didn't have by that time a sufficient method to counter the competition...who are we kidding here? If Spectre was really to be such an Uber-card as you guys want us to believe, then why the heck did it need to result to such methods in the first place? Either do it properly out front and add some sort of occlusion culling or hierarchical Z or if you have to cheat then use clipping planes str8 away for the timedemos *shrugs*

Needless to say that if they had been so confident that they are that far ahead of NVIDIA they wouldn't even had considered a dual chip sollution for Spectre in the first place; they intended to abandon multichip sollutions past Spectre if all would have went according to plan. Primary reason being that they increase costs significantly and are times worse to sell, let alone scale down in pricing as time goes by.

***edit: I remember the "small visual errors" very well in some maps; a mess is more what would describe it even with 60fps capped and that conservative "tiling" (for heaven's sake...) on....

 

Strange that people even try to talk this feature good, after the enormous bashing nVidia has received for 'cheating'.

 

I didn't say the K2 had two TMU's per pipe, but I should've explicitly stated it had one each like I did for GF2.

Similar to 30-50%? Or are you suggesting GF3 doesn't even remove 30% of occluded pixels? Or even more than 50%?

You answered your own question wrt PowerVR. Their occlusion culling works perfectly more or less all the time. As a side note, K2 has another advantage in having trilinear TMU's...

Amusingly enough though, it worked in controlled cases.

Now we're drifting into politics. Rampage's actual design philosophy was advanced features and quality over speed, that's why they were going to do dual-chip. Hell, it still only had one TMU per pipeline, though they were Trilinear capable.

Personally I could never get it to work at all on my V5 while it was working.

But people at x3dfx have definitely been able to go from "unplayable" to "playable" (say, 40fps to 60fps, or 25fps to 40fps) with conservative settings. I know you find it hard to believe, but it has been done.

 

All architectures up to Series4 had just one TMU AFAIK. I meant KYROIII or STG5500 if you prefer.

Just early Z in a non Z pass first application isn´t even going to reach 30%. Q3a in question has an average overdraw of 3.39, where early Z alone reduces it to 3.17. On NV2x and upwards you have to encount the memory controller, caching and what not since q3a benefits quite a bit from memory optimisations. If else riddle me why P4´s with their quad pumped bus are the q3a engine´s favourites.

Even a TBDR will be bound by the engine´s BSP and it´s downsides. Granted since the game is completely fillrate limited a K2 benefits a lot in fillrate, but it can´t overcome completely the idiotic behaviour of the BSP. There´s a reason why more and more games result to portal rendering these days, even if the manual implementation costs the developer quite a bit more time.

I don´t recall KYRO to have trilinear TMUs. It´s performance hit with pure trilinear on, compared to bilinear was quite large. However with texture compression enabled it used to fetch 16x samples from one mipmap on the fly, which minimized the performance penalty over plain bilinear. I used bilinear/2xVertical for most games when I had it.

So do cheats also. Your point?

What´s the deal with the number of TMUs per pipe anyway? When you have loopback functions a secondary TMU per pipe back then would have been redundant. Plus the dual chip model with 16 TMUs would have most likely ran out of bandwidth and the read efficiency would drop into the gutter.

I tried it both on the V3 and the V5. Both - the second to a lesser degree- used to produce artifacts in certain spots you just had to know where to look at; and that with the most conservative settings. It´s the same old story with about everything, just like the K2 showed some annoying poly gaps with Supersampling turned on, not many were able to see them. They were mostly visible in dm7 of q3a and in a couple of racing sims. It´s not a rare occurance anyway, if the gaps are white they´re just more apparent.

 

K2 had (still has) 2 texturing pipelines, each of which could apply one texture per clock.

Correct, in the normal sense. It did have a "pseudo-trilinear", for compressed textures only, than computed a lower MIP map level on-the-fly.

What? That doesn't make sense. The only way, AFAICS, that there could be gaps is if there were holes in the original model, in which case they'd also show up when AA was off (athough only ~1/4 as often).

 

2*1 for K2
4*1 for K3

Where's my mistake there? I said TMUs not pipelines.

Whole paragraph from my former post:

Could be I phrased something badly in the bolded part, but where was I wrong there?

I don't think we mean the same thing. It randomly appeared/disappeared only in very few cases and only with either 2xVertical or 2*2, horizontal didn't expose those. Cases I remember from the top of my head were fine white parallel lines in the far clipping distance on road textures (only in a few maps) in F1 2001 and NFS PU (randomly appearing and disappearing) and little white parallel and horizontal lines in a couple of spots in dx7 q3a. As I said there were no such side effects with 2x Horizontal.

 

Err but the total is still 2. You said one TMU so I just wanted to make sure there was no confusion.

I didn't say you were wrong! In fact, I distinctly said "correct"! :? All I was doing was adding some extra information for the benefit of other readers.

Odd. Very Odd. There is no fundamental difference between horizontal and vertical filtering. The only thing I can think of is that maybe there are either

• some T-Junctions in their models that happen to fall between samples when the image is rendered at a low-enough resolution or
• There is a feature in their far clipping code that rounds the wrong way so that a miniscule gap occurs.

 

Not that it´s related at all, but I did have the feeling that Vertical did offset LOD by -0.5 (estimated value), while Horizontal didn´t. I did ask back then, but no one ever answered that question, thus I´m rather uncertain about it. Speaking of is there any particular reason why PowerVR has for two samples exclusive modes for either x or y (tile size maybe being a reason?).

I meant 1 TMU per pipeline. I had clarified it one post before the one you noticed and missed making it clearer in the next one; my apologies.