I just found out how bad Ati's angle dependent AF looks

[K.I.L.E.R]

I made a OpenGL demo of a box with RGB pixels by accident (the texture really was supposed to be a picture) and I had AF disabled in my CP.

I looked at the horendous texture aliasing with trilinear filtering by itself and ended up going into my CP to enable AF 16x + Quality.

I ran it again and it looked really nice and the pixels were nicely blended together and no texture aliasing was shown until...
I started to move around the Z-axis, then I was watching the sides of the box shimmer like there was no AF enabled, on top of that it looked like it had only trilinear filtering because it wasn't blended like the rest of the box.

Why haven't I noticed this in any games and only in my silly little useless demos?
I couldn't notice this under UT03, SS, SS:SE, BF1942, BF:V or any other game which is good.

Will the R420 allow an option to disable this hardware optimisation?
In games I can see a use for this optimisation but when testing GL programs it really does rear it's ugly head out.

Is there any walkaround?

Will any IHV offer programmable AF algorithms anytime soon?

 

[anaqer]

Will the R420 allow an option to disable this hardware optimisation?

How do you make a hardware optimisation optional?

 

[Kombatant]

I doubt it's a hardware optimization, i think it's in the driver.

 

[tEd]

Will the R420 allow an option to disable this hardware optimisation?

How do you make a hardware optimisation optional?

good question

besides we don't really know whether the r420 has the same hardwired angle dependencie as r3xx just yet unless Dave want to leak some info

 

[K.I.L.E.R]

I doubt it's a hardware optimization, i think it's in the driver.

I don't know, I hope you are right because I read in the past it was in the hardware.

I just want to force angle dependent AF off in my program through an extension or through the CP.
I don't care which way as long as it can be done.

 

[Bjorn]

besides we don't really know whether the r420 has the same hardwired angle dependencie as r3xx just yet unless Dave want to leak some info

We also don't know if the NV4X AF is "hardwired" angle dependant.

Why haven't I noticed this in any games and only in my silly little useless demos?
I couldn't notice this under UT03, SS, SS:SE, BF1942, BF:V or any other game which is good.

The complaints i've seen comes mostly from people that play slower paced RPG games.

 

[tEd]

besides we don't really know whether the r420 has the same hardwired angle dependencie as r3xx just yet unless Dave want to leak some info

We also don't know if the NV4X AF is "hardwired" angle dependant.

i'm pretty sure it isn't.

 

[Kombatant]

Wouldn't it be a waste of valuable space to "hardwire" such a trivial thing on-die?

 

[tEd]

Wouldn't it be a waste of valuable space to "hardwire" such a trivial thing on-die?

it doesn't waste space. If you would implement non-angle AF and then optimize it with the driver would cost you more trans. than vica-versa

 

[volt]

We also don't know if the NV4X AF is "hardwired" angle dependant.

IMO that would make no sense. Why would they want to hardwire the new algorithm when they can disable it inside the driver -- what I'm getting at are Quadro cards, certainly developers would not appreciate this. But I could be very wrong as well

 

[Kombatant]

Wouldn't it be a waste of valuable space to "hardwire" such a trivial thing on-die?

it doesn't waste space. If you would implement non-angle AF and then optimize it with the driver would cost you more trans. than vica-versa

I would imagine that having transistors doing specialised work to exclude certain angles would be more costly than doing normal Trilinear AF. At least the way I think of it; you do angle-agnostic AF first and then you substract the angles you choose. And I agree with volt, that's the way i was thinking as well.

 

[Bjorn]

IMO that would make no sense. Why would they want to hardwire the new algorithm when they can disable it inside the driver -- what I'm getting at are Quadro cards, certainly developers would not appreciate this. But I could be very wrong as well

I agree that i wouldn't make that much sense, especially if the can disable it in the driver. And they have the option for trilinear/brilinear so why not go all the way. But i remain cautious until i see the checkbox

 

[tEd]

Wouldn't it be a waste of valuable space to "hardwire" such a trivial thing on-die?

it doesn't waste space. If you would implement non-angle AF and then optimize it with the driver would cost you more trans. than vica-versa

I would imagine that having transistors doing specialised work to exclude certain angles would be more costly than doing normal Trilinear AF. At least the way I think of it; you do angle-agnostic AF first and then you substract the angles you choose. And I agree with volt, that's the way i was thinking as well.

but that would be very stupid IMO if that would be the case. Add trans. for less quality seems like a bad idea to me.

 

[Kombatant]

Wouldn't it be a waste of valuable space to "hardwire" such a trivial thing on-die?

it doesn't waste space. If you would implement non-angle AF and then optimize it with the driver would cost you more trans. than vica-versa

I would imagine that having transistors doing specialised work to exclude certain angles would be more costly than doing normal Trilinear AF. At least the way I think of it; you do angle-agnostic AF first and then you substract the angles you choose. And I agree with volt, that's the way i was thinking as well.

but that would be very stupid IMO if that would be the case. Add trans. for less quality seems like a bad idea to me.

Now you know why i believe that this must be in the driver

 

[tEd]

Wouldn't it be a waste of valuable space to "hardwire" such a trivial thing on-die?

it doesn't waste space. If you would implement non-angle AF and then optimize it with the driver would cost you more trans. than vica-versa

I would imagine that having transistors doing specialised work to exclude certain angles would be more costly than doing normal Trilinear AF. At least the way I think of it; you do angle-agnostic AF first and then you substract the angles you choose. And I agree with volt, that's the way i was thinking as well.

but that would be very stupid IMO if that would be the case. Add trans. for less quality seems like a bad idea to me.

Now you know why i believe that this must be in the driver

i don't think so because it would make me really mad

 

[radar1200gs]

But if the added transistors also add speed...

Anyway, driver or hardware implimentation I just hope there will be a way for the user to choose between the two modes.

 

[Bambers]

r3xx etc angle depedant AF is hardware. They're saving transistors by doing and estimation of the calulcations that normally would be needed to do 'perfect' AF.

Why nv40 has even a driver option for angle dependant AF (if they can indeed do af nv3x style) I really have no idea. I would have thought that given the lack of bad angles that tend to show the gains in speed are pretty minimal. I've always read it's more of a transistor saving than speed gain.

 

[DemoCoder]

Angle dependent AF is a transistor budget gain. Think about that when you speculate that the NV40 must have a non-angle-dependent mode.

 

[tEd]

Why nv40 has even a driver option for angle dependant AF (if they can indeed do af nv3x style) I really have no idea.

benchmarks?

 

[Bambers]

Angle dependent AF is a transistor budget gain. Think about that when you speculate that the NV40 must have a non-angle-dependent mode.

I was, I'm not entirely sure how it works but my thoughts are that having angle dependant AF as well as non angle dependant stuff would need 2 sets of 'af calculation parts' which seems a bit of a waste of transistors for a few % in benchmarks :?