Radeon 9700 NDA Lifted

just for the record :

Source : http://www17.tomshardware.com/graphic/02q3/020718/radeon9700-08.html

 

There is simply no point to scale to 256 VPUs on a single board. If I wanted to do a renderfarm, I would simply put a bunch of them on separate cards and use software to coordinate the rendering. There are already pre-built RISC boxes that work like postscript printers that you slap onto your network and push Renderman RIB files to for rendering. Your renderfarm management software slices and dices the scenes and sends the jobs off to the various boxes.

Trying to put 256 chips on a single card behind a single AGP bus is insanity. It won't work because of heat, size, and power density requirements (25W * 256 = 6400 watts per "board"!) and it still won't get you A Bugs Life in real time. But if you want to accelerate offline rendering, then 3 or 4 on different PCI cards in cheap Linux/Intel boxes would make sense.

 

I'm not sure they said that as a serious statement, merely an example of what could be done. If ever a unti was needed then they would likely be similar in arrangement to the Quantum AAlchemy units.

 

it you build it they will come .......

 

Good points there. Two years back people were all over the place for more texture units per pipe (like: "Yeah 4 textures in a single cycle - wow man!") but multi-texturing is being replaced with the ability apply more textures per pass (not so much per cycle).

The demand has changed since Quake III. Doom III is a perfect example: The chip has to jongle on the fly between single texturing stenciled shadows to multi-pass texture quality rendering. And as I said before: With 8 pipes and loads of textures in future games we not have an unlimited amount of texture fetch access anyway.

(Of course of you have ekstra silicon to burn then sure; go ahead and add more texture units. But I'm not sure they will pay off big time right now).

 

I have been watching the ATi press launch and the ATi Radeon 9700 was developed by the 'ATi Nintendo team.'

 

NVIDIA must be downsampling the frame buffer before mapping alpha textures if they are having trouble with AAing them. I don't see what other problem they could have.

Frame buffer compression looks like a good match for MSAA, sort of a brute force approach to FAA that works for polygon intersections. Too bad it doesn't look to support higher AA than 6X.

I'm a little puzzled by the TMU/pipe configuration. They must be able to get 1 trilinear pixel/pipe/clock. Otherwise it strikes me as a useless decision since no one is running bilinear anymore. In fact, AFAIC 4 TMUs per pipe is fine, just use them all for AF.

 

Incorrect.

Generally with multisample AA, you get the following problem with alpha textures: You take one texture sample, but you take N depth samples. If the texture sample passes the alpha test, all of the N samples will. Similarly, if the texture sample fails the alpha test, all will fail. Because of this behavior, you won't get antialiasing on the internal "edges" because there is no interpolation between passing and failing texels.

 

Are you saying that if the alpha test suceeds all sub samples are given the green flag regardless of their individual depth tests? Normal filtering should work fine for the "alpha edges" within the texture.

 

I don't think that's the case. However, the pixels would get rejected if the alpha test fails, regardless of the z test. Which is the opposite of what you said. Maybe normal filtering just isn't good enough to match the quality of the AA in the rest of the scene.

 

No, depth test still matters. But that only helps with intersecting triangles.

Filtering does work fine if you use alpha blending. But then you need to depth-sort those triangles to avoid artifacts, and it's slower.

If you only use alpha test, it's either "all samples pass" or "all samples fail" since they use the same color/alpha value.
Only the triangle edges (coverage mask) and intersection edges (depth test) get AAed with multisampling.

 

- You are making a bunch of assumptions here
- Texture caching and bandwidth requirements are two separate things. Sure texture caching helps if you have a lot of reuse..But don't forget you need to fetch the data atleast once into the cache
- Your comments apply to games that are not texture bandwidth limited; ie they probably use a lot of low-res textures or compressed textures...most last generation games(including quake3). Something like UT2003 or Doom3 is a completely different story
- Again, the issue is not whether you read texture sample from memory more than once..just compute the bandwidth for reading a 32-bit texture sample..assume a multitextured background in a game where you a have 1024x1024 texture mapped onto to say a 16x12 rectangle. Do the math...

 

Don't knock compressed textures. DXTC is a stunning technology. The best thing about it is that you can go from 256x256 to 512x512, take up half the space in vram of a 32-bit original, and STILL get double the performance (because of improved fetch, tiling and cache efficiency). And in these cases it looks better 99% of the time (i.e. all those that aren't things like the sky in Q3).

I've never seen anyone complain about texture compression if, when it is enabled, the resolution of all textures is doubled in this manner, although nvidia's DXT1 problem is a bit of a downer sometimes.

Note that Epic were one of the first big users of compressed textures in Unreal Tournament's add-on pack, and the textures they improved in this way look stunning. Nowadays I find playing UT without the enhanced textures quite strange.

 

Sounds like an "upper management" type of solution, marketed by "upper management" thinking PR people. They needed to appeal to these people as well. Sshhhh.

 

Huh? Ever heard of mip mapping?