When is 4X FSAA Not 4X FSAA?

[parhelia]

Maybe, but instead of dissing the Xabre, look at this review from Digit Life!
According to Digit Life, the GeforceFX 5200 Ultra 128MB gets beaten by a SiS Xabre 400 64MB in ALL the tests they tried : Return to Castle Wolfenstein, Serious Sam II and even UT2003! (UT 2003 being NV optimised!)
You will be better off with a Xabre 64MB then with a GeforceFX 5200 Ultra 128MB!
Even the ageing Geforce3 Ti 200 outperforms that crappy GeforceFX 5200 Ultra!

http://www.digit-life.com/articles2/retro/index.html

 

[demalion]

Compared to 2x SS it blurs textures, not to no AA at all. There is more texture color information being blended for the pixel output. "Super sampled Quincunx" without the trademarked sampling pattern.

AFAIK Supersampling on R8500 doesn't affect texture LOD, so textures look worse with AA than without.

OK, been trying to understand what you mean. I presume you mean that sub sample positions for textures are not unique texture samplings, but I don't see where that is demonstrated.

It is the unique sample positions added that I am proposing add color information...what do you mean by textures look "worse"? Do you just propose that in the way someone might say AF can look worse than point sampling in a screenshot in that blending other color information into pixels might not be as sharp? I can see how this might conceivably be proposed for magnification, but not minification.

Educate me if you mean something else, or have a demonstration of the former in mind, i.e., that "B" is not a unique texture sample.

 

[Xmas]

What I mean is that if you use supersampling or a higher resolution, you should use higher-res mip levels. If you use the same mip levels with supersampling as without supersampling, you get "overfiltered" textures.

Of course you can adjust LOD bias to improve this, but it's not done automatically.

 

[Bambers]

On the 8500 texture lods are just stuffed with AA.

with 2xquality in opengl (1x2 supersample) the mipmaps along the floors are pushed out as they should be, however the mipmaps along the walls get closed as do ones on surfaces facing the player/camera.

Only the jittered 2xquality mode in d3d (no fog) seems to adjust miplevels correctly.

 

[demalion]

I'm not talking about pushing back mip levels, I'm talking about extra samples from the existing mip levels.

Magnification : blends more (for < 2x sampling count) but texture data is not lost.
Minification : adds extra color data to the existing pixel outputs.

I'm still not seeing how that is "stuffed"...blurred compared to 2x SS, yes, but not to no AA.

 

[CarstenS]

Maybe, but instead of dissing the Xabre, look at this review from Digit Life!
According to Digit Life, the GeforceFX 5200 Ultra 128MB gets beaten by a SiS Xabre 400 64MB in ALL the tests they tried : Return to Castle Wolfenstein, Serious Sam II and even UT2003! (UT 2003 being NV optimised!)
You will be better off with a Xabre 64MB then with a GeforceFX 5200 Ultra 128MB!
Even the ageing Geforce3 Ti 200 outperforms that crappy GeforceFX 5200 Ultra!

http://www.digit-life.com/articles2/retro/index.html

Your link says otherwise than you did in your post (regarding Xabre400 and 5200 ultra)

 

[Stefan Payne]

They also say the FX 5200 brings "true multisampling"* to nV's low-end part; I was under the impression the GF4MX also used "true multisampling." I also thought nV 2x was RGMS, not OGMS.

Their games selection was a tad limited, too. Couldn't they find something other than an FPS to benchmark? Warcraft 3 or Commanche 4, maybe?


* If by "true multisampling" they mean "fake multisampling," then I agree.

The strange thing is that that 'Multisampling' of the GF4 MX look like Multisampling but the Chip looses half of their Fill Rate and Geometry Thorughput.

Multisampling with the losses of Supersampling ??

 

[Arun]

The strange thing is that that 'Multisampling' of the GF4 MX look like Multisampling but the Chip looses half of their Fill Rate and Geometry Thorughput.

Multisampling with the losses of Supersampling ??

Hmm, never heard of that problem.
What I *do* know, though, is that there *are* some strange behaviours on many MSAA implementations.

According to tests I made and which were ran by people at nV News having a GeForce FX, in a fillrate limited condition, 2x AA is 100% free. 4x AA got a slight hit.

On a R3xx, the same tests were run by someone else, and both 2x AA and 4x AA had a performance hit. The 4x AA hit was lower, though.

I've got to say that this might not be 100% reliable, because the GFFX was two times slower at this test. However, it should never be memory limited, as the PS program is 20+ instructions and the memory bandwidth usage is minimal ( don't even really use Z, IIRC )

My guess that there's some type of DAC cost - or at least some type of filtering cost for AA, and whose cost is quite signifiant, and that the GeForce FX is made with free 2x AA in mind for that. It remains mysterious why the GeForce FX display a 4x AA hit as high, if not higher, than the Radeon 9700 who got a 2x AA hit, though - any idea?

My guess is that the NV30 uses a different system for 2x AA . If that's true, then you might wonder if it would be possible to include such a system for 4x AA in the NV35, or maybe at least profit more of the 2x AA implementation, maybe seeing it as 2x AA with one filtering method and 2x AA in another filtering method.


Uttar

 

[Crusher]

Maybe, but instead of dissing the Xabre, look at this review from Digit Life!
According to Digit Life, the GeforceFX 5200 Ultra 128MB gets beaten by a SiS Xabre 400 64MB in ALL the tests they tried : Return to Castle Wolfenstein, Serious Sam II and even UT2003! (UT 2003 being NV optimised!)
You will be better off with a Xabre 64MB then with a GeforceFX 5200 Ultra 128MB!
Even the ageing Geforce3 Ti 200 outperforms that crappy GeforceFX 5200 Ultra!

http://www.digit-life.com/articles2/retro/index.html

That's the non-Ultra 5200 you're looking at. The 5200 Ultra beats the GF3 Ti 200 in all tests, and also beats the regular GF3 and ties the Xabre 600 in Serious Sam:SS, though it loses to both cards in RtCW and UT2003. However, since the tests were all run with texture compression off and maximum texture detail, and knowing the SiS Xabrific texture magic, I'm guessing those Xabre 600 and 400 scores don't correspond to very good looking images. Notice the Xabre 400 even beats the Radeon 9500 64MB in RtCW, despite having both a lower core and lower memory clock.

Anyway, I don't see the point in arguing about low end cards anyway. None of them are worth the price, IMO. If you can't dig up a little more cash for a 9500 Pro or a Ti 4200, you don't really have much of a right to complain about lousy performance.

 

[demalion]

Uttar:
Hmm...a 20 instruction PS 2.0 shader? That is a pretty computation limited benchmark to begin with, since the bandwidth and fill rate hits of adding AA don't interact with the main workload (i.e., that would be a good case for proving "free super sampling AA", not a "free" multisampling AA method). I'd say both cards' AA performance penalties are being masked by the test.

However, taking into consideration examples of prior 2x AA discussion, the results for the nv30 dont' seem surprising at all, since you remove Z buffer writes. The performance hit for nv30 2x AA seems bandwidth (and memory footprint) determined, and you've both curtailed bandwidth use and memory footprint by avoiding z buffer usage.
The R300 has a performance hit because it doesn't blend in the DAC, so it's AA hit can't be masked by cutting bandwidth use. Increasing computation usage should do it, though.

Oh, I'm assuming you are referring to this test.

 

[Arun]

Yeah, that's the thread alright.

Here's the D3D code:

        g_pd3dDevice->SetStreamSource( 0, g_pVB, 0, sizeof(CUSTOMVERTEX) );
        g_pd3dDevice->SetFVF( D3DFVF_CUSTOMVERTEX );
		g_pd3dDevice->SetRenderState( D3DRS_LIGHTING, FALSE );
		g_pd3dDevice->SetRenderState( D3DRS_ZENABLE, D3DZB_FALSE );
		g_pd3dDevice->SetRenderState( D3DRS_ZWRITEENABLE, FALSE );
		g_pd3dDevice->SetRenderState( D3DRS_ALPHABLENDENABLE, FALSE );
		g_pd3dDevice->SetPixelShader( m_pPixelShader );
		g_pd3dDevice->SetTexture( 0, g_pTexture );

		g_pd3dDevice->DrawPrimitive( D3DPT_TRIANGLELIST, 0, NumberOfTriangles);
		g_pd3dDevice->DrawPrimitive( D3DPT_TRIANGLELIST, 0, NumberOfTriangles);
		g_pd3dDevice->DrawPrimitive( D3DPT_TRIANGLELIST, 0, NumberOfTriangles);

Note that there is a Z Buffer ( 16-bit, though ). It just isn't activated.

And here's the PS file code:

ps_2_0
dcl_2d s0
dcl t0.xy
def c0, 0.9, 0.7, 0.7, 0.5

texld r5, t0, s0	// 00+01 = 01
lrp r0, c0, r5, c0	// 01+02 = 03
mul r0, r0, r5 		// 03+01 = 04
mul r1, r0, r0 		// 04+01 = 05
mad r0, r1, r1, c0 	// 05+01 = 06
mul r1, r0, c0 		// 06+01 = 07
mul r0, r1, c0 		// 07+01 = 08
mad r1, r0, r0, r0	// 08+01 = 09
mul r2, r1, r5		// 09+01 = 10
mul r2, r0, c0 		// 10+01 = 11
min r0, r2, r5		// 11+01 = 12
lrp r1, c0, r5, r0	// 12+02 = 14
rsq r2.x, r1.x		// 14+01 = 15
sub r0, r5, r0		// 15+01 = 16
max r1, r2, r0		// 16+01 = 17
rcp r2.y, c0.y		// 17+01 = 18
min r3, r2, r1		// 18+01 = 19
add r4, r5, c0		// 19+01 = 20
max r6, r3, r4		// 20+01 = 21
mov oC0, r6

Of course, it outputs complete crap, I just cared about having enough computations.

Anyway, thanks for the explanation demalion. But those tests would seem to indicate no DAC merging is done at all with 4x AA. The V5 did DAC merging even with 4x AA, no? Any reason why nVidia couldn't do it? Cost? But then why not do part of the merging in the DAC, and part of it in other ways?


Uttar

 

[demalion]

Well...I had that question too...

Here is some discussion.

Pay attention to the relevance of the corrections I received (and beware the sloppiness of my math ), both in the link from the prior post and this one.

 

[CarstenS]

Heh, funny you should say that. My FSAA Viewer actually only does render a single frame when windowed (unless a WM_PAINT message is received from Windows). Fullscreen though does render multiple frames.

Too see if anything strange is going on (when windowed), you could just keep tapping the space bar. That will invert the colours (and forces the frame to be re-rendered) so you'd be able to see if some frame blending is occuring since eveything should be grey.

Well, i did exactly as you said with 4xAA set to agressive mode. I did not see any greyishness nor any shifted sample-patterns.

Also, in fullscreen Applications other than your tester i did not notice unsual line flickering or something that would hint in any way to 2x2xAA-images being blended or alternated.

Do you have any other idea how to make this issue show up?