R300 Mip-mapping LOD problem. (Warning, big screen shot)

[DemoCoder]

Perhaps bringing such an obscure IQ bug to light might increased the chances of it getting fixed vs being filed in a bug tracking database. Or perhaps, as with NVidia, it might be a symptom of some driver tricks we don't know about.

*chuckle* Considering that according to the comments here ATi knows nothing about this software and has never seen it, that would be a neat "nVidia driver trick" indeed... Something from the "Psychic Hotline," maybe--that sort of "driver trick"?.....

Why would they have to know anything about this specific software? It's perfectly reasonable that an optimization they applied to everything they tested on (mainstream games) works in 99.9% of titles, but has a degenerate border case that fails.

 

[Sharkfood]

Hmm.. the original screenshot doesn't look anything like the (now) suggested situation. If so, you don't see some form of instant bilinear and definately not at the angle your screenshots suggest.

More appropriately, it looks like the original screenshots are exhibiting the zbias/MT issues that have been discussed here in the past. Through various driver revisions, this has been mostly fixed but developers still encounter it from time to time.

 

[Jamm0r]

More appropriately, it looks like the original screenshots are exhibiting the zbias/MT issues that have been discussed here in the past. Through various driver revisions, this has been mostly fixed but developers still encounter it from time to time.

Hmm.. care to post a link to such a discussion? Searched the forums for it but can't find anything relevant. Allow me to say, however, that I don't see the relevance of zbias here.

 

[Hyp-X]

I've seen quite some z fighting on the R300 and it doesn't look like this.

Also notice that while the sudden change of miplevel is best visible on the road, if you look closer it continues on the ground as well.

 

[WaltC]

Why would they have to know anything about this specific software? It's perfectly reasonable that an optimization they applied to everything they tested on (mainstream games) works in 99.9% of titles, but has a degenerate border case that fails.

Well, you likened it to what nVidia did, which in the case of 3D Mark 03 could not have been accomplished without intimate experience with the 3D Mark software.

It's also possible, isn't it, that in this case it could be a bug in the application engine...? I don't think there's enough evidence to hypothesize a "degenerate border case" for the drivers and the exclusion of application-specific causes.

 

[Jamm0r]

Also notice that while the sudden change of miplevel is best visible on the road, if you look closer it continues on the ground as well.

Yes, this might not so visible in that shot, but the hard mip lines traverse the full length of the monitor.

 

[LeStoffer]

Also notice that while the sudden change of miplevel is best visible on the road, if you look closer it continues on the ground as well.

Yes, this might not so visible in that shot, but the hard mip lines traverse the full length of the monitor.

Dunno, but as I stated before it seems to me that something is up with AF on the third miplevel (after the second arrow). It's too blurry. Have you set different levels af AF for the different miplevels? Maybe this could invoke a bug?

 

[Jamm0r]

Nope, we are not setting any form of Aniso in the engine. All we do is enable tri-linear filtering for both texture stages.

 

[Tagrineth]

Nope, we are not setting any form of Aniso in the engine. All we do is enable tri-linear filtering for both texture stages.

Setting Aniso in the driver overrides that.

Try setting aniso in-engine.

 

[Jamm0r]

Roger that! I was in a hurry and didn't realize he was suggesting setting Aniso in the engine. Good idea!

 

[Sharkfood]

It looks a lot like zbias/bugs from the original screenshot- when used with multitexturing. It's impossible to predict since I have no idea what texture layers you are using for the ground plane.

If you do a search on just the keyword "ZBIAS" you will see at least a dozen threads on such subject. Derek Smart ran into complete textures dissappearing from the original bug, and I also posted some MT examples where subsets of layers were missing on poly edge boundries (looks alot like your original screenshot, but still unsure of what MT/layers are involved in your examples).

I've never seen the bilinear/aniso issue as your screenshot would suggest. Only at an extreme worst case angle does it even become visible, and even at this- it's at a substantially greater angle (closer to 45 degrees)

 

[OpenGL guy]

It looks a lot like zbias/bugs from the original screenshot- when used with multitexturing. It's impossible to predict since I have no idea what texture layers you are using for the ground plane.

Z-bias and multitexturing have nothing to do with each other. Multitexturing is a texture operation. Z-bias is a Z buffer operation. Totally unrelated.

If you do a search on just the keyword "ZBIAS" you will see at least a dozen threads on such subject. Derek Smart ran into complete textures dissappearing from the original bug, and I also posted some MT examples where subsets of layers were missing on poly edge boundries (looks alot like your original screenshot, but still unsure of what MT/layers are involved in your examples).

I knew you'd bring up this example. I said it before so I'll say it again: There never was a Z-bias/multitexture bug in the driver with DS's application. And if you bring up Morrowind, I'll say the same thing as the application never uses Z-bias.

 

[banksie]

This rendering problem looks identical to what has been plauging me when running 'Giants:Citizen Kabuto' on my 9700 - very noticeable mip-map lines instead of a nice smooth rendering.

Giants is also a Dx7 rendered title and I have 4xAA 8xAF forced on in the drivers.

Philip

 

[Sharkfood]

Z-bias and multitexturing have nothing to do with each other. Multitexturing is a texture operation. Z-bias is a Z buffer operation. Totally unrelated.

I provided examples in the past where the issue is clearly illustrated. The "fix" wasn't implemented in drivers, but in engine code- and ATI support was most helpful in providing solutions for the issue.

It was more of a case of what NVIDIA's drivers allowed, but was wrong from the approach angle (i.e. not implemented correctly from the start, but never caught as it worked on other platforms in the past).

I knew you'd bring up this example. I said it before so I'll say it again: There never was a Z-bias/multitexture bug in the driver with DS's application. And if you bring up Morrowind, I'll say the same thing as the application never uses Z-bias.

I really can't speak for DS or his solution- only that his issue seemed related to my own and I explored the same paths that he did. The only difference was my problems were resolved (in code) and I have no clue if his were/were not. I only brought up the issue as my screenshots and issue were included in some of his threads at the time.

 

[Jamm0r]

..

 

[tEd]

Well, got the final answer from ATI today:

"In a multitexturing situation, only texture 0 will have trilinear filtering and AF when quality AF is enabled from the control panel. All other textures will get bilinear filtering plus AF.

If AF and bilinear/trilinear options are specified in code, and the AF setting in the control panel is left at "Application", then the texturing options will be exactly as specified in code."

Some of you weren't too far off the mark on this.

damn that was it. As i already mentioned in this thread that i experienced problems in some games mostly ut engine(ut2003,postal,u2) based where tril/AF didn't work right even when i had quality AF enabled in the CP. Now after reading this i set AF to application pref. and changed the anisotropie in ut2003.ini from anisotropie=1 to anisotropie=16 and bang tril/AF worked as it should everywhere.

Thank you very much

 

[mczak]

Well, got the final answer from ATI today:

"In a multitexturing situation, only texture 0 will have trilinear filtering and AF when quality AF is enabled from the control panel. All other textures will get bilinear filtering plus AF.

If AF and bilinear/trilinear options are specified in code, and the AF setting in the control panel is left at "Application", then the texturing options will be exactly as specified in code."

This would also perfectly explain why 3dmark03 gets higher scores if you force aniso in the driver than setting it in 3dmark03 itself - pretty close to what I suspected why there is a difference.

 

[tEd]

Well, got the final answer from ATI today:

"In a multitexturing situation, only texture 0 will have trilinear filtering and AF when quality AF is enabled from the control panel. All other textures will get bilinear filtering plus AF.

If AF and bilinear/trilinear options are specified in code, and the AF setting in the control panel is left at "Application", then the texturing options will be exactly as specified in code."

This would also perfectly explain why 3dmark03 gets higher scores if you force aniso in the driver than setting it in 3dmark03 itself - pretty close to what I suspected why there is a difference.

yes it's most likely.

ut2003 anatalus flyby
1024*768@32 cat3.4 r9700pro
no aa

16x quality AF driver forced
0.886894 / 119.158989 / 367.623199 fps -- Score = 119.180992
16x AF application
0.872876 / 91.345520 / 299.989349 fps -- Score = 91.370117

 

[mczak]

This would also perfectly explain why 3dmark03 gets higher scores if you force aniso in the driver than setting it in 3dmark03 itself - pretty close to what I suspected why there is a difference.

yes it's most likely.

ut2003 anatalus flyby
1024*768@32 cat3.4 r9700pro
no aa

16x quality AF driver forced
0.886894 / 119.158989 / 367.623199 fps -- Score = 119.180992
16x AF application
0.872876 / 91.345520 / 299.989349 fps -- Score = 91.370117

Just curious, but is this the same with older drivers? I've some strange suspicion the recent performance improvements with newer drivers (3.2/3.4 ?) when AF is enabled is just because of this trick that not all texture stages are using trilinear filtering.
Is there a aniso tester out there which uses multitexturing? That would also reveal other potential optimizations, such as not applying anisotropic filtering to all texture stages.