r420 may beat nv40 in doom3 with anti-aliasing

london-boy said:
jvd said:
Evildeus said:
GF FX 5950 can't do more than 8*....

right so doesn't that mean the radeons are doing more aniso ?

Thats what i get from seeing af 8/16

You're probably right, jvd, although we should check before accusing. If those tests are with R420 doing 16x and NV40 doing 8x, then i really do not see the point of taking the test.

not accusing just asking .

I find it strange how they put that.

I also though the 6800s are capable of 16 af .
 
jvd said:
Evildeus said:
GF FX 5950 can't do more than 8*....

right so doesn't that mean the radeons are doing more aniso ?

Thats what i get from seeing af 8/16

I'm guessing that the 5950 is the only card doing 8X AF. It would be pretty lame if they didn't use 16X on the NV4X. But weirder things have have happened.
 
jvd said:
can u give me a quick summer of ultra shadow culling ?

It's a z-scissor test. It allows you to reject incoming fragments that cannot be affected by the light source (if you are doing illumination), or, it allows you to reject fragments which can't possibly be in shadow from that light source POV.

This saves stencil fillrate, and can also save shader fillrate as well.

You understand how z-buffer culling works right? If you go to draw a pixel, and if its z-value shows it is already covered by another pixel, you can early-Z reject that pixel, saving fillrate.

Well, UltraShadow (EXT_depth_bounds_test extension) allows you to set a global Z range (zmin/zmax) which will reject fragments outside that range.
 
DemoCoder said:
jvd said:
can u give me a quick summer of ultra shadow culling ?

It's a z-scissor test. It allows you to reject incoming fragments that cannot be affected by the light source (if you are doing illumination), or, it allows you to reject fragments which can't possibly be in shadow from that light source POV.

This saves stencil fillrate, and can also save shader fillrate as well.

You understand how z-buffer culling works right? If you go to draw a pixel, and if its z-value shows it is already covered by another pixel, you can early-Z reject that pixel, saving fillrate.

Well, UltraShadow (EXT_depth_bounds_test extension) allows you to set a global Z range (zmin/zmax) which will reject fragments outside that range.
yes i understand z buffer culling. And thanks to u i can grasp ultra shadow.

It sounds like a good feature. Didn't they introduce this with the geforce 3 ?
 
Bjorn said:
jvd said:
Evildeus said:
GF FX 5950 can't do more than 8*....

right so doesn't that mean the radeons are doing more aniso ?

Thats what i get from seeing af 8/16

I'm guessing that the 5950 is the only card doing 8X AF. It would be pretty lame if they didn't use 16X on the NV4X. But weirder things have have happened.

that is a good point and one that makes sense .

Although it could very well be only at 8x .
 
DemoCoder said:
3dMark03 could also be limited by vertex shader performance too. Remember, it does shadow volume extrusion in the vertex shaders.
Right, but then you'd think the X800 would come ahead.

It also might use the Z-buffer incorrectly, which could disable Hyper-Z HD. Dunno.
Who's to say this use of the z-buffer won't be the case for other games? I myself have noticed that the Radeon 9700 didn't seem to do as well in games using stencil shadows as my GeForce4 as it should have (should meaning comparing it vs. games that didn't use stencil shadows). Has this been fixed?

If I remember correctly, the issue is that Hyper-Z cannot be used if the stencil buffer is cleared while the z-buffer is not cleared. I would have thought that this would be a requirement for using multiple lights with stencil shadow volumes.
 
No, I believe it started in the NV3x, but I could be wrong. It doesn't make much sense to use it until you are doing global/unified D3-style shadows. And since there have been paultry few OGL engines designed for that, you aren't seeing it used much.

Imagine if 3Dc had been introduced with R300. Since there are paultry few PolyBump-style games (I believe FarCry is the first to use it alot), you wouldn't have seen alot of use for normal map compression, since most games aren't heavy users of hi-res normal maps created by reducing multi-million polygon geometry loads.

Ah, the pain of waiting for developers to catch up and use high end features!

p.s. there's also the issue of lag in Microsoft supporting it. It will take a revision of DX (9.1 or 10) to add a new function for setting such a scissors test, unless some trick is found to extend DX, and no doubt, some IHVs are resisting it.
 
from the b3d reviews

gametest 2, 1600x1200, no af

r420
image031.gif


nv40
image025.gif
 
thnx

I wonder if something is broken.

My 9700pro on an athlon xp 2500+ on gt 2 in 3dmark2001 gets 29 frames

your telling me the x800xt only manages to get another 21 frames over it ?

I dunno that can't be right
 
jvd said:
thnx

I wonder if something is broken.

My 9700pro on an athlon xp 2500+ on gt 2 in 3dmark2001 gets 29 frames

your telling me the x800xt only manages to get another 21 frames over it ?

I dunno that can't be right

gt2 in 3dmark03 not 01.
 
AlphaWolf said:
jvd said:
thnx

I wonder if something is broken.

My 9700pro on an athlon xp 2500+ on gt 2 in 3dmark2001 gets 29 frames

your telling me the x800xt only manages to get another 21 frames over it ?

I dunno that can't be right

gt2 in 3dmark03 not 01.

He meant '03, there is not "gt2" in 2001. And if there were, it wouldn't run at 29fps on a 9700... ;)
 
Another point of consideration is will the 6800u 3DMark03 performance increase with Dx9.0c? I would envisage that if the speculation that DX9.0c will mainly offer an increased performance path over DX9.0b then it should effect all DX9 titles.
 
Why would there be any increases for DX9.0c? This is just a tweak to enable the specific implementation of SM3.0 in GF6, its highly unlikely to affect anything to do with SM2.0 or before.
 
london-boy said:
He meant '03, there is not "gt2" in 2001. And if there were, it wouldn't run at 29fps on a 9700... ;)

Well I was looking at some 3dmark numbers earlier, a X800 pro was getting 91 fps in gt2.









Of course it was running at 700mhz... :D
 
It may effect games which dynamically link with D3DX due to the tweaks to FXC. Also, developers can issue patches with the recompiled shaders. (for example, FXC now uses NRM macro, whereas previous versions expanded it, which makes it easier for the 6800 drivers to detect a "free norm" opportunity)

In general, the biggest performance bumps will come with later versions of the 6800 drivers.
 
DaveBaumann said:
Why would there be any increases for DX9.0c? This is just a tweak to enable the specific implementation of SM3.0 in GF6, its highly unlikely to affect anything to do with SM2.0 or before.

It's been mentioned that in FarCry using SM3 path over SM2 will be just a performance boost for 6800u and that there will be no visual differences, I also understand it's going to be the same with UT2004. If this is the case then surely 3Dmark03 would enable this path too or possible Nvidia would force it.
 
THe_KELRaTH said:
DaveBaumann said:
Why would there be any increases for DX9.0c? This is just a tweak to enable the specific implementation of SM3.0 in GF6, its highly unlikely to affect anything to do with SM2.0 or before.

It's been mentioned that in FarCry using SM3 path over SM2 will be just a performance boost for 6800u and that there will be no visual differences, I also understand it's going to be the same with UT2004. If this is the case then surely 3Dmark03 would enable this path too or possible Nvidia would force it.

The thing with FarCry is that until we have more powerful CPUs, the game aint gonna get much faster anytime soom.
 
Back
Top