Why such little drop in performance in X800 when AF applied?

digitalwanderer said:
Really? And here I've always been forcing AF thru control panel. :oops:

Where exactly is the option in Radlinker to force it on all levels...is that just setting the AF slider to "forced" and "highest quality"? (I'm utterly in love with Radlinker lately, WAY TOO COOL! 8) )

Yeah setting af to "forced af" in radlinker gives you the mode I was talking about. I guess you should also have the texture preference slider on high quality although you probably would anyway.

If you dont see any quality problems when forcing af (examples where there are areas which look worse with af on due to this tradeoff include: halo, mafia, Unreal tournament (original), Undying) using normal control panel options then your probably best not enabling it. In general image quality should be the same whether its on or off as only the first stage often needs more filtering. UT2k3 theoretically should look better with the hidden mode incidentally although it costs alot of performance.
 
croc_mak said:
This could be happening on ATI drivers if the application does not specify both mag and min filters to be anisotropic. Nvidia hardware does not have a separate controls for mag and min for aniso.

This is a well known issue. Hope the glidwrapper folks are reading this
I am reading this, but you missed the fact that my wrapper uses OpenGL. There are no anisotropic min/mag filters in OpenGL, max desired anisotropy is a separate state.

Try this. Same problem on R300 class cards w Cat 4.7. Start the program, switch on aniso ("A"), and there's your shimmering. Toggle the trilinear base filter twice ("T") and it's gone.

edited: Changed link to a more reliable hoster :rolleyes:
 
zeckensack said:
croc_mak said:
This could be happening on ATI drivers if the application does not specify both mag and min filters to be anisotropic. Nvidia hardware does not have a separate controls for mag and min for aniso.

This is a well known issue. Hope the glidwrapper folks are reading this
I am reading this, but you missed the fact that my wrapper uses OpenGL. There are no anisotropic min/mag filters in OpenGL, max desired anisotropy is a separate state.

Try this. Same problem on R300 class cards w Cat 4.7. Start the program, switch on aniso ("A"), and there's your shimmering. Toggle the trilinear base filter twice ("T") and it's gone.

edited: Changed link to a more reliable hoster :rolleyes:

Your test is messed up.

IF i fore 16 aniso in the control panel i don't get any shimmering . X800xt pe 4.7 cats offical.
 
jvd said:
Your test is messed up.

IF i fore 16 aniso in the control panel i don't get any shimmering . X800xt pe 4.7 cats offical.
Ah, confirmation :D
Does toggling trilinear off/on (press "T" twice) help?
 
zeckensack said:
jvd said:
Your test is messed up.

IF i fore 16 aniso in the control panel i don't get any shimmering . X800xt pe 4.7 cats offical.
Ah, confirmation :D
Does toggling trilinear off/on (press "T" twice) help?

If i set it to force i get nothing.

If i leave it up to your app i get very bad shimmering. If i press t i can see the transistions . If i turn turn on the t again the shimmering gets pushed bakc father
 
jvd said:
If i turn turn on the t again the shimmering gets pushed bakc father
That it gets pushed back -- instead of going away -- may be due to the X800 series' AF optimizations. The original purpose of the program was to evaluate texture filtering in motion, because some things (such as negative LOD bias, taking too few samples etc) cannot be seen on still images. "Random noise" is closest to real world texture content btw.

The three black/white textures are expected to show hefty luminance pumping even on "perfect" filter hardware, because of the lack of inline gamma compensation. It will almost never be that bad in real games (Tron 2.0 is the only exception I know of).
 
I'm only doing it with the random noise .

I'm telling u exactly whats wrong.

However you have the app selecting aniso is wrong. When i force 16x aniso I have no shimmering. When i use the app to select it i have shimmering.

I can use fraps to show u what i mean .
 
jvd said:
I'm only doing it with the random noise .

I'm telling u exactly whats wrong.

However you have the app selecting aniso is wrong. When i force 16x aniso I have no shimmering. When i use the app to select it i have shimmering.

I can use fraps to show u what i mean .
You don't need to show me, I believe you right away :)
That's what I was talking about when I wrote that "... ATI's current drivers do not properly handle application control of aniso filtering. You'll get a lot of texture shimmering".

I believe my code is doing things correctly. If it doesn't, I'd like to hear about it.
 
I am no coder. But the fact that this doesn't happen in farcry when i leave it up to the aplication is one of the reasons why I believe it is donig something wrong.

I'm not claiming its your fault. Perhaps there is some developer support that your missing with the proper way to implement aplication control .

I offered videos in case i'm not explaining myself. Anyway I got a new case and I"m going to move my watercooling rig over and instal my new athlon 64 mobo and chip. So i might not be on again tonight.
 
jvd said:
I am no coder. But the fact that this doesn't happen in farcry when i leave it up to the aplication is one of the reasons why I believe it is donig something wrong.
This is OpenGL. Farcry is DirectX Graphics ;)
jvd said:
I'm not claiming its your fault. Perhaps there is some developer support that your missing with the proper way to implement aplication control .

I offered videos in case i'm not explaining myself. Anyway I got a new case and I"m going to move my watercooling rig over and instal my new athlon 64 mobo and chip. So i might not be on again tonight.
That won't be necessary, but thanks :)
 
jvd said:
Shouldn't the driver behave the same under both open gl and direct 3d .
OpenGL/DXG drivers are two separate entities. One may have bugs the other doesn't, and anyway, in this case the API is different. DXG treats anisotropic as a first-class filter method, while OpenGL treats it as a separate state that complements an independent filter method. With such a different behaviour, I don't think you can share that specific piece of code between both drivers.

You might have a point for OpenGL "drivers" that are implemented as mere Direct3D=>OpenGL wrappers, but that's not the case for the big two IHVs AFAICT. Possibly true for Matrox (though that's just a rumor I picked up, and may well be false).
 
Do texture stage optimisations work Under OpenGL? Originally texture stage opts only existed under D3d for Nvidia cards,

I dont have anyway to test it (A program that would work)
 
Ouch. Should I send a proper bug report, or are there enough ATI employees reading these boards? :D

edit: the report has been sent. Hope it helps.
 
So what is the conclusion to this? Why does the X800 take a smaller hit to AF when its fillrate is approximately equal to the 6800GT? That's assuming that my assumption that filtering is based on fillrate is correct.

I don't know filtering well(read:I don't know it at all, except the textbook basics of bi/trilinear), since my work involves drawing lines and rarely do I use textures. Anyone can point me to the mathematics behind anisotropic filtering?
 
Back
Top