G80 vs R600 Part X: The Blunt & The Rich Feature

So we know for sure that an MSAA rendertarget can be compressed? I seem to remember someone saying that render-to-texture is uncompressed, but I could be mistaken and/or thinking of a console.

Well, I wasn't sure that the RBE's were the things doing the MSAA resolve. If they were, it makes no sense to me that a "hardware" resolve is any faster than a software resolve. NVidia complained about this in their CoJ rant, and everyone said this was the reason R6xx was slow in AA. I figured that the only way this can really be true is if there was some parallel hardware to do the resolve, maybe near the display engine.

I guess the datapath between the RBEs and shader units is a reason.

Well, there's a difference between realtime on a 1-2MPix screen and 60 GTex/s decompression (for two of them) without tying up any resources.

 

At least that what was grabbed from some sample scenes - maybe some games do generate new shaders on the fly or in different levels.

I'm not sure though, whether I'm legally allowed to make this stuff public. Maybe just a diagram with the achieved fillrates normalized to a 7900 GT would suffice?

 

Using excessive memory/bandwidth with MSAA on NVIDIA cards (relative to ATI cards) surely sounds plausible, which is why CSAA used on NV cards makes a lot of sense when moving beyond 4xAA as a bandwidth-saving technique. Unfortunately there isn't much testing done by reviewers nowadays with 16x CSAA, probably because there is nothing directly comparable on the ATI cards.

Anyhow, the whole "clever" vs "brute-force" concept is a semantical argument, just a play on words. Depending on how one spins something, it is easy to make one or the other approach appear "clever" or "brutish". The most important thing is how the product performs for the intended market at a given price point, be it gaming/GPGPU/developer applications.

 

As i said before he who dies with the most frames wins

 

Sure nvidia is still doing display-engine msaa resolve? IIRC nv30 could do this, but only with 2xAA whereas it could do 2xAA or 4xAA with a copy resolve.
I'd have thought they've abandoned display-engine resolve, as the drawbacks aren't worth the effort (higher memory usage, fullscreen only). It did in fact use less bandwidth though since with fullscreen you can do pageflip (so no copy necessary), and afair that was pretty much the reason it even existed.

 

I know that any format can be compressed. I'm talking solely about the case where the rendertarget is a texture. I guess these textures can only be accessed in the shader using the Load() function instead of Sample() or tex2d(), now that I look into it a bit more closely, so there aren't any orthogonality problems. It does make sense to use the compression hardware, but like I said, I heard otherwise for texture rendering.

Well that's just it: R6xx MSAA performance has never been as fast as their RV5xx counterparts, at least in terms of performance drop.

That's basically what I was talking about. I figured that ATI would do something similar. Maybe not directly to the display device like NVidia, but a separate unit nonetheless.

The situations are rather different. Megatexture is about only having the data needed consuming the RAM. Your engine is still going to require the same billions of texture accesses per second.

To have full speed in today's games, you need to be able to decompress 160 point samples per clock in RV770. There's no way to do that economically except with fixed function hardware away from the shader engines.

 

There is a huge difference. Fixed function fog maps to a few general ALU instructions and is used at most once per fragment, while S3TC decompression can be required for several texture fetches and is a very specialized sequence of operations which would probably result in several dozen ALU instructions. If you want to do it efficiently there is hardly anything that could be reused for other operations, so there is no point in integrating it into the ALU.

 

I'm not disagreeing with you here. This process, however, can be more costly than just rendering uncompressed in the first place.

Not sure what you're referring to, but no, I don't think you can make that generalization. Shadow maps are different, environment maps are different, etc.

Oh I did. But just because I felt there's a "wrench in the comparison" doesn't mean I think the AA drop was as small as it should have been. RV770, for example, has the same 2x Z rate without AA, but it has a smaller drop than even R580, IIRC.

He's talking about texels in memory, not texture fetches, and only per texture at that. "Texel" is a term that has been given two meanings. It really comes from "texture element", i.e. the data elements in the texture, but GTexel/s refers to texture fetches executed by the shader engine, each needed 4 (or more) texels from the cache.

Megatexture reduces the amount of texture data needed for a scene (given certain constraints) by creating a tighter bound - relative to normal engines - on what really has a chance to be accessed, but has no effect on the texture operations needed to render it.

 

Near zero net overdraw. With good sorting this can include lots of gross overdraw.

In theory, yes, but tests show it pretty close to 2x:
http://www.computerbase.de/artikel/...50_rv770/3/#abschnitt_theoretische_benchmarks
I wouldn't say R5xx is wasteful of bandwidth, but I will acknowledge that it has more bandwidth per shader pipe per clock, thus being less saturated and more able to absorb the hit of AA. R600, though, is even more "wasteful" of BW than R580, so if that's a factor in R580 having a low % drop w/ AA, it should help R600, too.

Jawed, you're way off base here. Your estimates for the number of fetches needed for a scene are off by over an order of magnitude. Megatexturing does not reduce bilinear fetch count much at all. It definately does not reduce the number of fetches to the point where in-shader decompression is feasible, and Xmas agrees with me.

 

When it in fact still achieves about 8.500 MZixels/sec. with 4x AA enabled (3,4 Z/ROP/clk), odds are, the Z-Only rate without AA is utterly bandwidth limited.

I've got a similar test (thx to Marco Dolenc) and it shows HD2900 XT and HD4850 on par without AA with the HD4850 pulling ahead with 4xAA enabled. Normalized to clk and # of ROPs, HD4850 get's about 3,39 Z while HD2900 is pushing out a mere 1,83 Z.

edit:
Even more interesting are the achieved throughputs with 8xAA enabled.
HD4850: 3,9056 z/clk/ROP
HD3850: 1,9041 z/clk/ROP
HD2900: 1,8567 z/clk/ROP
GTX280: 3,1279 z/clk/ROP
9600GT: 5,1307 z/clk/ROP

 

Actually, I can get it to do 4X Z...it depends on the app used to test that. Fillrate Benchmark(which I guess is loosely based on MDolenc's fillrate tester) seems to go oddball about testing Z-it gets me about 5X Z on an 8800GT and about 2.5X Z on the 4850, which you'll agree are both wrong. Using Archmark you get the correct 4X Z on the 4850.

 

Interesting. Care to post the ArchMark numbers?