Radeon 9700 NDA Lifted

[Evildeus]

You probably won't be able to pick up an R300 in a store for almost 30 days. That places the real (non-paper) launch around August 18th. The NV30's paper launch will probably be in Nov, with availability in Dec, or, they might opt to skip the paper launch and just launch everything in Dec. In any case, the distance between the R300 and NV30 in terms of real delivery is probably more like 3-4 months, but that's a guess.

One this part i was more thinking that nVidia would paper lauch the NV30 on late August/early september and the cards would be available late october/early november. Should be the target time table i think.

Well at least 2 cards will bring real improvements to the market during 2002.

 

[DemoCoder]

Man, the flash demos (and movies) on ATI's site are awesome. I await orgasmic response from DX9 enabled visuals.

 

[Reverend]

Knowing what we all know (i.e. suspect), personally, I would wait a few months.

It's a no contest for someone considering a GF4Ti4600 and this one and needs a card now but I would wait...

 

[LeStoffer]

Heres a key part:

It is not yet clear if the omission of a second texture unit per pixel rendering pipeline was indeed a smart choice. Under multi texturing conditions, GeForce4Ti4600 is theoretically able to supply just the same amount of pixels per clock as Radeon 9700. The fill rate test of 3DMark2001 SE hinted in the same direction. The score of Radeon 9700 is very close to the result of GeForce4Ti4600.

That'll explain the 8 pipelines. If they are working on a .13um part I wonder if they will add that back in.

Good catch.

It's not clear to me, however, whether a single texture unit per pipeline might not turn out to be a reasonable standard on all vendors PS 2.0 pipelines. I'm not sure that you'll really need more texture units with 8 pipelines and the advanced rendering with PS 2.0 (like the number of texture inputs per pass go up to 16, 32 address instructions and new stuff like 4 render targets that might complicate things like dependency etc.)

I guess that the days of a Voodoo2's dual-texture ability just isn't that fancy anymore.

 

[demalion]

I find this interesting:

Improved antialiasing — ATI's latest version of SMOOTHVISION antialiasing retains the ability to use programmable jitter patterns, but it implements multisampling instead of supersampling. Also, ATI finally caught on and adopted anisotropic filtering under the SMOOTHVISION banner. Multisampled AA will handle edges, and aniso filtering handles textures. Together, they're more efficient than supersampling, and they look better, in my book. Plus, R300 applies gamma correction when blending color samples, which provides higher visual fidelity output.

AA modes on this chip can take advantage of HyperZ, which, it turns out, wasn't the case on the Radeon 8500. Also, the R300 sidesteps one of the big drawbacks of multisampling AA because it can handle "edges" inside of alpha- blended textures properly. Existing multisampling implementations, like NVIDIA's, don't touch those jaggies.

OK, we covered the the fog a bit...but has anyone done a comparison on AA with the HyperZ functions turned off and turned on? I'm wondering if something new was mentioned by a tech at that conference, even if it was just to "damage".


EDIT: Maybe he just meant this:

In case of 6x FSAA the Z-compression (as well as color compression) can be up to 1:24, as for FSAA the frame and Z buffer blocks are utilized as well and the six corresponding sample blocks are compressed as one.

 

[JF_Aidan_Pryde]

Oh dear,

Who would have guessed that NVIDIA would loose the Quake3 trophy on July the 18th 2002...

 

[Dave Baumann]

It's not clear to me, however, whether a single texture unit per pipeline might not turn out to be a reasonable standard on all vendors PS 2.0 pipelines. I'm not sure that you'll really need more texture units with 8 pipelines and the advanced rendering with PS 2.0 (like the number of texture inputs per pass go up to 16, 32 address instructions and new stuff like 4 render targets that might complicate things like dependency etc.)

Well, with 16 textures per pass the need for multitexturing in hardware will definitely be rising as these capabilities are used more, so I’ll wager they will move back up to 2 textures (or more) when the silicon process allows them.

However, this possibly raises more questions than it actually answers, because theres more to it than just the number of TCU’s you have per pipe. For instance, 8600’s ability to address 6 textures meant that each pipeline also had 6 texture registers, giving a total of 24 texture registers. With the need for 16 registers in DX9 how does R300’s pipeline handle this? If it build it up over 16 cycles then that would mean that each pipe has 16 registers giving a total of 128 registers for the chips – which I assume would be huge; alternatively does it use pipeline combining meaning that some/many of the actual pixel pipes are not doing anything for much of the time when multitexturing is in operation but would cut down on the total number of registers used.

Questions, questions…

 

[Nagorak]

Here's the calculated FPS based on the "normalized" scores in the Anandtech review.

Unreal Tournament 2003 (DM-Antalus)
1024x768x32 High Detail Settings
Radeon 9700: 130.4
GF4 Ti4600: 94.5
Parhelia: 54.4
Radeon 8500: 57.6

Unreal Tournament 2003 (DM-Antalus)
1280x1024x32 High Detail Settings
Radeon 9700: 87.8
GF4 Ti4600: 59.3
Parhelia: 35.1
Radeon 8500: 37.9

Unreal Tournament 2003 (DM-Antalus)
1600x1200x32 High Detail Settings
Radeon 9700: 63.3
GF4 Ti4600: 41.1
Parhelia: 24.6
Radeon 8500: 25.2

---------------------------------------------------------------

Unreal Tournament 2003 (DM-Asbestos)
1024x768x32 High Detail Settings
Radeon 9700: 210.3
GF4 Ti4600: 178.2
Parhelia: 100.4
Radeon 8500: 91.1

Unreal Tournament 2003 (DM-Asbestos)
1280x1024 High Detail Settings
Radeon 9700: 144.3
GF4 Ti4600: 115.4
Parhelia: 65.5
Radeon 8500: 58.9

Unreal Tournament 2003 (DM-Asbestos)
1600x1200 High Detail Settings
Radeon 9700: 104.1
GF4 Ti4600: 82.0
Parhelia: 46.9
Radeon 8500: 42.0

---------------------------------------------------------------

Jedi Knight 2
'demo jk2ffa' 1024x768x32
Radeon 9700: 122.5
GF4 Ti4600: 125
Parhelia: 90.5
Radeon 8500: 123.5

Jedi Knight 2
'demo jk2ffa' 1280x1024x32
Radeon 9700: 123.2
GF4 Ti4600: 124.4
Parhelia: 74.9
Radeon 8500: 116.9

Jedi Knight 2
'demo jk2ffa' @ 1600x1200
Radeon 9700: 124.3
GF4 Ti4600: 113.0
Parhelia: 65.9
Radeon 8500: 93.2

---------------------------------------------------------------

Serious Sam 2: The Second Encounter
'Little Trouble' 1024x768x32
Radeon 9700: 115.2
GF4 Ti4600: 100.2
Parhelia: 67.4
Radeon 8500: 58.2

Serious Sam 2: The Second Encounter
'Little Trouble' 1280x1024x32
Radeon 9700: 102.6
GF4 Ti4600: 72.9
Parhelia: 49.5
Radeon 8500: 45.3

Serious Sam 2: The Second Encounter
'Little Trouble' 1600x1200x32
Radeon 9700: 77.6
GF4 Ti4600: 51.7
Parhelia: 37.3
Radeon 8500: 32.1

 

[DemoCoder]

Did anyone else catch that ATI is also doing framebuffer compression as well for storing multisamples? There have been rumors of the NV30 having 4:1 compression when 4XMSAA is turned on, and here ATI are claiming 6:1 when 6XMSAA is turned on. Must be the same method, so NV30 won't have this as an advantage. Thus, the R300 is already very efficient Hyper-Z, anisotropic, and MSAA wise, but and it has a 256-bit CROSSBAR bus. This means NVidia's IMR efficiency won't help them because ATI now has everything the GF4 has in terms of efficiency tricks.

The NV30 will need atleast a 256-bit bus (or edram, etc) if it is still an IMR, otherwise, the only thing I can see saving them is a radical departure from their IMR architecture, with say, tiling. The only problem with this is, the future looks to be HEAVILY textured, so even a tiler would benefit big time from more bandwidth.

 

[Sharkfood]

demalion-

On AA + HZ on the 8500- although this is something I'll definately test out of interest, I dont know if this quote refers to a real difference in HyperZ function in the 8500, or just an optimists way at looking at the increased number of z-buffer accesses required with multisampling. The way it reads:

AA modes on this chip can take advantage of HyperZ, which, it turns out, wasn't the case on the Radeon 8500.

.. could kind of mean either way. From "AA modes on this chip", I would speculate this means the new HZ is exploited even moreso with MS vs SS and therefore stands much to gain? Time for some benches.

 

[LeStoffer]

However, this possibly raises more questions than it actually answers, because theres more to it than just the number of TCU’s you have per pipe. For instance, 8600’s ability to address 6 textures meant that each pipeline also had 6 texture registers, giving a total of 24 texture registers. With the need for 16 registers in DX9 how does R300’s pipeline handle this? If it build it up over 16 cycles then that would mean that each pipe has 16 registers giving a total of 128 registers for the chips – which I assume would be huge; alternatively does it use pipeline combining meaning that some/many of the actual pixel pipes are not doing anything for much of the time when multitexturing is in operation but would cut down on the total number of registers used.

Questions, questions…

Indeed, indeed. I just think that a DX9 chip's ability to feed a single texture unit (or all 8 of them more correctly!) with up to 16 textures will pose bigger problem than the benefit of more texture units will add.

It'll take a lot of texture cache to feed those hungry pipes. In other words: If you have silicon to burn you might want to improve texture [fetch] efficiency rather than built another texture unit that will sit idle some of the time waiting for data.

Like Carmack said regarding the GF4 vs R8500 on Doom III: The R8500 can render it in one pass, but the GF4 is still faster because of its efficiency although it takes the chip 2 or 3 passes to render.

So questions abound indeed...

 

[Dave Baumann]

Did anyone else catch that ATI is also doing framebuffer compression as well for storing multisamples? There have been rumors of the NV30 having 4:1 compression when 4XMSAA is turned on, and here ATI are claiming 6:1 when 6XMSAA is turned on. Must be the same method, so NV30 won't have this as an advantage.

Which one said framebuffer compression? I only quickly read it but I only noticed Z-buffer compression; if it is only Z and NVIDIA has Frame buffer and Z buffer that will still be a performance advantage for NVIDIA.

Thus, the R300 is already very efficient Hyper-Z, anisotropic, and MSAA wise, but and it has a 256-bit CROSSBAR bus. This means NVidia's IMR efficiency won't help them because ATI now has everything the GF4 has in terms of efficiency tricks.

Well, HyperZ-III sounds remarkably unchanged so if NVIDIA has some more efficient occlusion culling routines, as has been suggested, there is also room to gain here.

 

[Bambers]

This truly sounds like a SmoothVision-II, with absolutely no idea what will really ship like the 8500. hehe. We heard the same kinds of things on pre-release R200, and what we got was first OGSS, then later *mostly* OGSS with slight jittering when circumstances were perfect (i.e. no fog, title specifity, etc.etc.).

From my observations and kipping the unfinished release (quack) drivers.

First we had what seemed to be a RGSS at 2xQ but in d3d it could be jittered perpixel, 4xQ looked to be 2xq on a supersample buffer 2x as wide. Again perpixel jittering in d3d. All other modes looked like OGSS.

Then in the 9xxx series all opengl went to OGSS and d3d non ordered was reduced to no-fog only it also seems only able to change the pattern a few times across the screen and this change looks like its rotated the pattern 90 degrees. The only reason I can think of for removing the AA from opengl was that it created an odd diagonal tear across the screen.

Now according to ATis r300 tech demo it seems that SV1 worked on a kind of v5 basis and mentions nothing of a psuedo random sampling pattern. I'm not quite sure how that fits in as there definately has been evidence of a changing pattern. I wish they'd get it sorted though .

Interesting to see in that tech demo that the r300 can use super and multisampling together, presumably in varying amounts. Its also boasting a 6x supersample perfromance increase over the r200s method.

 

[pascal]

I am still reading the Anand´s article but:
-The chip design is getting closer to CPU´s design (critical paths, clocks skews, etc...)
-This chip has a CPU like packaging
-It is the third GPU with a 256 bits bus 8)
-It is incredibly fast with benchmarks and using floating point precision pixels

Funny some people did not believe when talking about the possibilities above for consumer level GPUs

edited: congratulations to the ArtX design team, they are really good.

 

[Sharkfood]

One more post off topic concerning demalion's tidbit..

I moved some test data on this side R200 topic here:
http://216.180.225.194/~beyond3d/forum/viewtopic.php?p=23603#23603

 

[Matt Burris]

In Anand's article, in regards to ATI's anisotropic filtering, he says that it has been finally fixed. I remember reading here that it was never broken in the first place, now Anand is saying it's broken. Has it ever been confirmed if it is broken or not? I'm just confused.

Just the thought of 128-tap trilinear anisotropic filtering has me drooling.

 

[Dave Baumann]

AFAIK it was never broken - that was an implemtation choice so why sites are saying 'fixed'/'broken' is beyond me.

 

[Matt Burris]

AFAIK it was never broken - that was an implemtation choice so why sites are saying 'fixed'/'broken' is beyond me.

Well in that case, I guess cards that uses multisampling is broken as opposed to supersampling. lol I agree, I could never understand why they call it broken, when ATI clearly states it's adaptive anisotropic filtering. When I used the R8500, it certainly didn't seem broken to me.

 

[DrT]

NV30 is (also according Anand) AT LEAST 5 months away, that's almost half a year!!! Don't you think a chip coming two quarters later definitly should be faster? Even think about the improvmenents the memory semiconductor companies achieve in this timeframe (2 ns instead of 3 ns memory ...).

The Radeon 9700 is still 2 months away(Sept timeframe). That puts the NV30 just 3 months behind, not "almost half a year".

Still, the NV30, if it uses 0.13u, should have a decent advantage.

 

[jb]

Wow,

looks nice. I want to know more about the AA - Alpha texture/blend stuff as I always seem to bring that topic up And I also agree with Sharkfood as I want to see some more detailed reviews. I am glad that ATI trumpted nV as that will mean that nV will work harder to make the nV30 better which is good for all of us