Huddy says "R600"

Fine. So let's say you can do 8 pixels per clock given memory bandwidth constraints. If you're running at 4x AA with blending, since the ROP's of modern architectures, I believe, run at half-speed with blending enabled, the ROP's will only be able to output 4 pixels per clock. If you're running at 6x AA with blending, they'll only be able to output 2.666 pixels per clock (on average).

In the situation of framebuffer compression combined with higher-sample AA, the ROP's are not memory bandwidth limited.

Well, of course. But the compressability of the z-buffer similarly improves with higher-sample AA. I was thinking of increasing z-rate along with color sample output rate as implied in my argument.

 

At high res most pixels are magnified, so trilinear is a non-factor. NVidia also has more texture units than ROPs, so only with two textures are you guaranteed not to be ROP limited.

But, in the end I'm going to agree with you. 16 ROPs lets you fill a 2Mpix screen over 5000 times per second. Who cares if that gets halved.

I'd have to disagree here. First of all, magnification and trilinear optimizations mean you only fetch texels from two mipmaps maybe 20% of the time or less. Secondly single cycle trilinear costs almost as much as double the texture units. You need almost double the filtering hardware, double the data path from there to the texture cache (which needs double the read ports), double the request queue for memory loads, almost double the address calcs, etc. It's a waste of space compared to the more flexible option of additional bilinear texture units. NVidia abandoned this strategy with the Geforce2, even when they didn't have any trilinear opts.

 

Just curious, how do current GPUs do alpha blending with AA? If a pixel is compressed and all samples are identical, does it only take one cycle to do the blending?

Yeah, but this is relatively peanuts. Colour buffer for 4xAA, 1600x1200, FP16 is 60MB. Needs only 7% of a frame's available BW (on high end cards) in the worst case of every pixel being uncompressed, and will more likely be in the 2-3% neighbourhood.

 

That's a damned fine question. You'd think the hardware should be capable of that. I've never heard of such a thing, though, so it is conceivable that the functionality was never implemented just because it wouldn't have improved performance much.

Right. I think this is the real answer: for nearly any application, the ROPs aren't your limitation. I don't buy that bandwidth is what is influencing IHV's to increase fillrate while not increasing ROP's. This would be true if there was no frame/z-buffer compression, of course, but this is hardly the norm.

 

Yes, its clear that they have plenty room to manouver on the Z sample rate, as pointed out in the R520/R580 articles - RV530's Z sampling capabilities would be sensible across the entire range would be sensible for the next generation, but whether they will use it I don't know. RV530's ROP's also maintain their double Z rate even with FSAA as well.

That was the case for NV4x, not for G7x, nor any ATI - there's no ROP limitation in relation to the colour write performance for these parts.

Yes, which is why it was tacked on the end of a list of other bandwidth consumers. Point being, its still a requirement thats there in a bandwidth cnstrainted environment.

If you are at a point where you're at the maximum ROP utilisation you'll be at the limits of bandwidth, but more often, when you're rendering a scene, you'll not reach that ROP utilisation in the first place because you're backed up by shaders, so this is a balance. Before going to more ROP's I would guess that they will get more capable ROP's in terms of high depth rendering needing fewer cycles and more of the "right type" of samples for a particular operation per ROP.

 

The real question is, how much flaming will there be in the Rage3D forums if ATI doesn't release Win98 drivers?

 

Well, that makes some sense, but if they can't do as many z-tests, then there's not a whole lot of point. It seems like this functionality would only be used in cases where you could have a trivial z-pass, but I doubt that's going to be the norm.

 

It does for NV40 and later, not sure about ATI.

 

Is there anything to be a fan of at this point besides a codename? What do we know about R6xx?

 

First PC Unified Shader chip?

 

It's a very common phrase around here ("that thing"), I wouldn't interprete too much into it.

 

lol, maybe he had a temporary lapse into noobness

 

Maybe just because XP will be the "old" OS, since the world will instantly switch to Vista once it's released. You know, like when ATI expected everyone to switch to PCIe instantly back then, kinda...

 

This depends on texture resolution and scene composition. It's not hard to find cases where nearly everything is minified. You could be sampling from two mipmaps up to half of the time. I'd guess more than 20% typically.

Back then anisotropic wasn't the norm either. Tril. opts. reduce fetches less than high AF increases them.

8x AF needs up to 16 bilinear reads, maybe about 3 on average, while bandwith should increase much less due to cache hits. So the idea is to save some transistors by using half as many, more capable units, while retaining texturing speed when bandwith is less of a factor. But I really don't know if it would be worth it.

 

Well its not exactly stupid. There will be no DX10 for XP but of course the market of DX9 games will continue so one would assume these coming parts, aimed primarily at being the best DX9 parts yet, would have support for XP. However if ATI or Nvidia wanted they could absolutly cause "issues" to force Vista sales and DX10 adoption by dropping driver support for XP. It doesnt sound plausible but its possible. Though if anyone were to cause that it would be some strong arming from Microsoft. I think Devs across the world would go nuts if that ever happened.




ATIs PCIE transission was fine. All the way up to the X850 they had AGP and PCIE parts. It was the 7800GTX in PCIE only that slapped people. R520 didnt come until months later when people were no longer really surprised by the lack of AGP.

 

Microsoft is already doing that by not supporting any SM4 functionality in XP, though. If you want to make best use of your new DX10 card, you're going to need Vista, independent of whether or not IHV's have reduced driver support for XP (no driver support seems ridiculous to me).