Dynamic branching in 3dmarkxx ?

[Ailuros]

http://v3.espacenet.com/textdoc?IDX=US2005190195&CY=gb&LG=en&DB=EPODOC

http://v3.espacenet.com/textdoc?IDX=SG112989&CY=gb&LG=en&DB=EPODOC

 

[rwolf]

That last url is out of order execution.

 

[Pete]

IMO any new 3DMark should include 4x MSAA standard. Ditto AF.

I'd lean more toward 4xAA standard on 256-bit memory bus cards, 2x for 128-bit, and none for <128-bit. Or at least 4xAA for 256-bit buses.

But that sort of defeats the whole purpose of a single, common, comparable benchmark score. Of course, people have been reducing texture detail (and IHVs filtering quality) for years to boost their scores. Hmmm, maybe a premium edition (still with a free download) geared for at least 256-bit, 256MB cards? That way you'd have a common bench, but you'd also perhaps "get real" with how ppl use $250+ cards.

Wishful thinking, though. You can always enable AA yourself. It's nice AF is enabled by default, but now we've got AF quality levels to worry about. Perfection, you elusive, Nyquist-free bastard! /me shakes fist

 

[Rys]

Definite wishful thinking. Futuremark don't have the resources to audit drivers and filtering and AA quality differs aross IHV. It's an equivalent shader workload (hopefully!) benchmark and not much else. No AA or AF modes as standard for their next 3D benchmark IMO.

 

[trinibwoy]

http://v3.espacenet.com/textdoc?IDX=US2005190195&CY=gb&LG=en&DB=EPODOC

http://v3.espacenet.com/textdoc?IDX=SG112989&CY=gb&LG=en&DB=EPODOC

Spring refresh or G80?

 

[Martin Eddy]

Definite wishful thinking. Futuremark don't have the resources to audit drivers and filtering and AA quality differs aross IHV. It's an equivalent shader workload (hopefully!) benchmark and not much else. No AA or AF modes as standard for their next 3D benchmark IMO.

Yep nick from FutureMark has said as much.
http://www.beyond3d.com/forum/showthread.php?p=575741#post575741

AA and AF are still not "standardized", which means we have no control over them. It leads to the fact that we can't use them as default in 3DMark. They will however (as in our previous benchmarks) be available as options.

 

[Tridam]

Like I said, contrived and unrealistic. You'd need to build up a specially-made app to hit this case.

I'd really like to see that case

NV4x/G70 handle instructions per 1024 (64x16) pixel batches and NV4x use bigger batches with huge triangles (fillrate test optimisation ?) : (1024 x # of quad engines).

 

[Bob]

NV4x/G70 handle instructions per 1024 (64x16) pixel batches and NV4x use bigger batches with huge triangles (fillrate test optimisation ?) : (1024 x # of quad engines).

The batch size hasn't (really) changed between G70 and NV40. The scheduler, however, has changed significantly. Also, there is no 2D correletation with the batch size. A ~500x2 line will nicely fit in one batch.

 

[Tridam]

The batch size hasn't (really) changed between G70 and NV40. The scheduler, however, has changed significantly. Also, there is no 2D correletation with the batch size. A ~500x2 line will nicely fit in one batch.

Only true if '2' is the triangle height (with a very long triangle). Batches are created by columns of 64 pixels.