My R9700 experince and Aniso still "flawd"?

[KimB]

I've been accustomed (perhaps incorrectly ) to thinking of dy/dx as simply the change in y wrt x. Further, I'm accustomed to thinking of the second derivative, d2y/dx2 as the rate of change of y wrt x.

No, dy/dx is the rate of change of y with respect to x. The second derivative is the rate of change of dy/dx with respect to x (i.e. take the derivative, then take it again for the second one...). Second derivatives are related to curvature. With respect to time, they are generally related to acceleration. With respect to position, they are generally related to curvature.

Of course, I have a feeling you had this in mind all along...your wording was just not entirely correct.

 

[Bigus Dickus]

Perhaps. As I said, it's been a while, and as long as I get the correct answer I'm typically pretty pleased. I know what derivates in geometry/time domains relate to as far as acceleration, curvature, etc. I just had it in my head that the first derivative was a magnitude, and the second was a rate of change of that magnitude. After a bit more thought, I can see what that is absurd. The root equation is the magnitude, and the first derivative describes how one variable changes wrt another (rate).

Bah... that's why I liked applied courses more than fundamental math.

 

[KimB]

So do I, really

Once I got to differential equations, I really decided that pure math was just far too much work for me. I went into physics instead...where I might do the same amount of work, but at least the answer will be more than, "Um, wow, I guess that's interesting. Don't know when anybody will use it, but it's interesting..." but more of a, "Sweet! Now we can build a CPU with billions of transistors!" I figure that with the real-world applications, I'm much more likely to stick in and do the work required.

 

[darkblu]

i still don't get in what aspect the pixel shape is the same. the variation of texture coords across each pixel does depend on the polygon's orientation in eye/screen space. there's no such thing as single anisotropy degree per polygon (and this is how i interpret your 'pixel shape is the same' phrase) unless the polygon is viewplane co-planar, which is the sole exception.

Think about it this way:
- Take a simple rectangle with coords (0,0), (0,100), (100,0), (100,100)
- Apply a texture with tex coords (0,0), (0,1), (1,0), (1,1) respectively
- Now take the same rectangle with tex coords (0,0), (0, 0.5), (1, 0) (1, 0.5).

What happened? Same polygon, different texture coords, different pixel shape.

seems we're having troubles understanding each other.

i never said pixel shape could not be changed through changing the mapping onto the polygon - of course it can! i said:
1) pixel shape depends on the polygon orientation in eye/screen space (which does not preclude dependence on mapping, of course)
2) pixel footprint's shape varries across pixels unless the polygon is viewplane co-planar. your particular example would yield a uniform degree of anisotropy of 2 across the whole polygon IFF the polygon is viewplane co-planar.

now, correct me if misunderstood you, but my understanding of your original statement, and of your last post, is that pixel footprint's shape stays the same per given mapping. which is simply not true - pixel shape depends on the mapping and also varries across pixels unless the poly is flat on the viewplane. the most one can say is that pixel shape stays the same along the lines of constant z - but this is far from pixel shape staying the same polygon-wise!

 

[Nagorak]

Too much talk of math...

*head explodes*

 

[KimB]

the most one can say is that pixel shape stays the same along the lines of constant z - but this is far from pixel shape staying the same polygon-wise!

You can't even say that much. Quick example: Consider keeping z constant, and moving across a floor texture. At the left of the screen, the pixel would be skewed right (where skewed right means the texture pixels "bend" to the right as the you move towards the top of the pixel). At the right of the screen, the pixels would be skewed left. At the center there would be no skewing.

Those are quite different pixel shapes...

In general, the only time the pixel shapes are the same is when moving across a polygon that is viewplane coplanar.

 

[KimB]

Too much talk of math...

*head explodes*

*points to his dog*

Here, Sparky! Come clean up the mess!

 

[OpenGL guy]

now, correct me if misunderstood you, but my understanding of your original statement, and of your last post, is that pixel footprint's shape stays the same per given mapping. which is simply not true - pixel shape depends on the mapping and also varries across pixels unless the poly is flat on the viewplane. the most one can say is that pixel shape stays the same along the lines of constant z - but this is far from pixel shape staying the same polygon-wise!

Yes, I didn't say it well which is why I corrected myself later.

In my followup post, I noted that the derivatives are computed per pixel, that should be enough to imply that the pixel shape can change per pixel.

 

[darkblu]

the most one can say is that pixel shape stays the same along the lines of constant z - but this is far from pixel shape staying the same polygon-wise!

You can't even say that much. Quick example: Consider keeping z constant, and moving across a floor texture. At the left of the screen, the pixel would be skewed right (where skewed right means the texture pixels "bend" to the right as the you move towards the top of the pixel). At the right of the screen, the pixels would be skewed left. At the center there would be no skewing.

Those are quite different pixel shapes...

In general, the only time the pixel shapes are the same is when moving across a polygon that is viewplane coplanar.

ok, this time i was not precise in my wording, and you rightfully pointed it out. still, you, on your turn, were not precise in your correction on my statement, which oblidgates me to correct you

pixel shape can remain constant along the lines of constant z even in cases when the polygon is not viewplane-coplanar. it's a bit more complex than that. i'll try to use asci pictures, so behold (ed: dots are used in place of longer spaces because this BB client tends to compress long white spaces):

let's have a rectangular polygon, whose viewplane projection is a trapezoid

....----------
.../............\
../..............\
./................\
/..................\
-----------------

let this polygon have the following texture mapping, as seen in screen space

+....----------....+
...../............\
..../..............\
.../................\
../..................\
+----------------+

i.e. in object space, the above mapping would look like this:

+....---------------....+
......|.................|
......|.................|
......|.................|
......|.................|
......+------------+

i believe that if i say now that the above texture mapping, combined with the above orientation of the polygon in eye space would produce pixel footprint shapes which remain constant along the lines of constant z it would be sufficient for you (i.e. i would not need to put down the respective math equtions which would anyways be tiresome for the readers of this thread, incl. myself

 

[noko]

The per pixel is the key. As you map a texture on a polygon which is angle lets say away from you, the anisotropy or ratio of stretch for the texture will change as you head towards the farthest points. Now I know why ATI can have a very aggressive LOD, due to the fact that the shading of the poly closest to you won't have a large filtering penalty since of its adaptive nature. The pixels farthest from view will get the needed extra samples from the texture (up to 16) to define the correct color for the onscreen pixel.

So really ATI has an extremely adaptive anisotropic filtering method within a triangle or polygon. Combined this with overdraw this method must save alot of memory bandwidth, at least I would think so. My GF3 has a penalty of around 60% when doing 8x with tri-linear samples while the Radeon9700 with 16x has less then 10% from what I can see from the reviews.

 

[KimB]

The per pixel is the key. As you map a texture on a polygon which is angle lets say away from you, the anisotropy or ratio of stretch for the texture will change as you head towards the farthest points. Now I know why ATI can have a very aggressive LOD, due to the fact that the shading of the poly closest to you won't have a large filtering penalty since of its adaptive nature. The pixels farthest from view will get the needed extra samples from the texture (up to 16) to define the correct color for the onscreen pixel.

So really ATI has an extremely adaptive anisotropic filtering method within a triangle or polygon. Combined this with overdraw this method must save alot of memory bandwidth, at least I would think so. My GF3 has a penalty of around 60% when doing 8x with tri-linear samples while the Radeon9700 with 16x has less then 10% from what I can see from the reviews.

As I said before, noko, every anisotropic implementation is just as adaptive in this respect.

I believe the main thing that ATI does to make its implementation a little bit more adaptive is that it reduces the amount of anisotropic filtering for textures that don't need it (such as lightmaps). This is what nVidia is attempting to do to speed up the performance of their GeForce4's anisotropic. One other thing that may help the Radeons in the performance of their anisotropic is that there's no "enabling hit." That is, with a GeForce4, there's an overall performance drop just from enabling anisotropic, not from any additional samples used (I'm not entirely certain as to the reason for this drop...but it is there...).

 

[noko]

As I said before, noko, every anisotropic implementation is just as adaptive in this respect.

I disagree, Nvidia method indicates it samples everything regardless of anisotropy of what being rendered. Its rather steep performance degradation with less anisotropic filtering levels of the ATI cards indicate otherwise.

 

[KimB]

I disagree, Nvidia method indicates it samples everything regardless of anisotropy of what being rendered. Its rather steep performance degradation with less anisotropic filtering levels of the ATI cards indicate otherwise.

That's an impossibility, noko.

8-degree anisotropic filtering combined with trilinear will take up to 16 times as much fillrate as plain bilinear filtering.

Do you see the GeForce4's running at 1/16th the performance with 8-degree aniso + trilinear as they run the same scene with bilinear? Of course you don't. The performance hit is nowhere close to that (at worst, it's usually around 50% hit). No amount of optimization would cause any hardware that always uses the maximum amount of filtering for anisotropic to have the performance curves that the GeForce4 is exhibiting.

 

[RussSchultz]

That's not true. Due to texel caching, etc, you're not going to use nearly that much.

It was my understanding, also, that adaptive meant it only sampled when it needed to, whereas other anisotropic algorithms were 'dumber' and always took (for example) an 8x1 patch (even if the 8 samples ended up in the same place)

But I really don't know squat about any of the implementations. It'd be nice to hear from some of the designers.

HINT HINT.

 

[KimB]

Guys, guys. You don't need the word of a designer. It's obvious from the EXT_texture_filter_anisotropic specification, which was written by nVidia.

Similar to MIP mapping, there are specific limitations on how many samples can be used.

Oh, and sample caching would destroy the entire point of anisotropic, as that would mean that samples would be shared between pixels...

Here's the relevant portion:

It is also acceptable for an implementation to approximate the ideal functions Px and Py with functions Fx and Fy subject to the following conditions:

1. Fx is continuous and monotonically increasing in |du/dx| and |dv/dx|.
Fy is continuous and monotonically increasing in |du/dy| and |dv/dy|.

2. max(|du/dx|,|dv/dx|} <= Fx <= |du/dx| + |dv/dx|.
max(|du/dy|,|dv/dy|} <= Fy <= |du/dy| + |dv/dy|.

Here you see that any anisotropic implementation, if it does not perform to the exact formulae laid out previously in the specification, it must be within these boundaries.

Note that there is both a maximum and minimum. This means that for some surfaces, there is a maximum number of texture samples that can be taken.

It is acceptable for implementation to round 'N' up to the nearest
supported sampling rate. For example an implementation may only
support power-of-two sampling rates.

This sounds to me like a direct relation to nVidia's implementation, which appears to only support power-of-two sampling rates (at least, that's what the drivers would have you believe).

I imagine you'd like to say, "But, doesn't this mean that if 8-degree aniso is selected, that that is the only sampling rate supported?" To answer this, I'd like to point to the fillrate tests of 3DMark2k1. Here are the scores on my machine:

(aniso degree)single-texturing)/(multitexturing)
None: 507.9/1289.8
2x: 428.8/481.0
4x: 428.8/481.4
8x: 428.8/481.4

Now, what you are seeing here is, plain and simple, the "enabling hit" that I talked about previously with anisotropic. While no anisotropic should be applied to this fillrate test, apparently something is less efficient, though I'm not sure exactly what. The most obvious thing would be that the GeForce4 hardware reserves fillrate for potential extra anisotropic levels whenever any degree of aniso is enabled (As a quick side note, I accidentally had 2x FSAA enabled for these tests, so they are rather low for a GeForce4 Ti 4200, but that shouldn't make any difference in the conclusion).

Notice that there is absolutely no additional performance hit from increasing the degree of anisotropic. This is simply because no anisotropic is actually being applied (something else is, apparently, causing the performance drop...hopefully the NV30 will fully address this issue). All polygons in this fillrate test are parallel to the viewplane, in which situation the anisotropic specifications require no anisotropy.

Now, in games, there is most certainly a drop from enabling the higher degrees of anisotropy. This is obviously for the simple reason that real games actually have surfaces that use these higher degrees of anisotropy.

 

[noko]

In SS SE I was facing a wall straight on, nothing else in view, without anisotropic filtering using tri I got 271 FPS. With 8x anisotropic filtering with Tri-linear samples I got 161 FPS. Even with an isotropic viewed wall in front of me the GF3 dropped like a burnt out rocket when anisotropic filtering was turned on .

The drop would probably been more if I had a higher power cpu here, with tri-linear filtering only I think I was cpu limited.

Conclusion: Nvidia anisotropic filtering is not to adaptive.

 

[noko]

Now if the NV30 doesn't have an effective adaptive anisotropic filtering or is similar to the GF3/4 method, it won't matter how fast the memory or GPU is, the Radeon9700 will probably smoke it in high IQ filtering methods.

 

[DemoCoder]

In SS SE I was facing a wall straight on, nothing else in view, without anisotropic filtering using tri I got 271 FPS. With 8x anisotropic filtering with Tri-linear samples I got 161 FPS. Even with an isotropic viewed wall in front of me the GF3 dropped like a burnt out rocket when anisotropic filtering was turned on .

The drop would probably been more if I had a higher power cpu here, with tri-linear filtering only I think I was cpu limited.

Conclusion: Nvidia anisotropic filtering is not to adaptive.

That's not the conclusion. Did you try it with 2x and 4x? Didn't you see Chalnoth's post about the "enabling hit". Enabling any amount of anisotropic causes a performance drop for some reason, but if NVidia's implementation weren't adaptive that would imply that 8X, 4X, and 2X would always have different performance. That is, with 8X you take 8 samples no matter what and with 2x, you take 2 samples no matter what.

However, I think you will find that in fact, when facing a wall straight on that fills the view point, 8X won't run that much slower than 2X.

NVidia's implementation doesn't always take the maximum number of samples.

 

[noko]

However, I think you will find that in fact, when facing a wall straight on that fills the view point, 8X won't run that much slower than 2X.

You are correct,

SS SE, technology test, picked another wall

none 310 FPS
2x 199 FPS
4x 193 FPS
8x 189 FPS

Well I've been experimenting with isolating a single polygon like in QuakeIII and changing view angles from isotropic to anisotropic. The frame rate on my GF3 really doesn't change that much, which once again indicates something pretty static. Still I am not convinced what I am doing is causing enough anisotropy to really see an adaptive filtering scheme. Well time to sleep, maybe tomorrow, chow.

Oh, my previous conclusion is obviously pre-mature.

 

[DemoCoder]

BTW, one explanation for the "enabling hit" of anisotropic filtering on the GF4 is that perhaps it takes over the second TMU of the pipeline even when it doesn't need to. That is, it is still adaptive and takes less than the maximum anisotropy setting when needed, but the mere fact that anisotropic is switched on disables the second TMU. That's why the hit is super large in the multitexture test, but minor in the single texturing test.

Thus, perhaps the problem with the anisotropic implementation on the GF4 is not that it is taking more samples than it needs to and hogging bandwidth, but that the second TMU gets disabled and thus multitexturing takes a huge performance hit.

If it was a bandwidth limitation that caused the texel fillrate to get cut in half in the fillrate benchmarks, then why does 2x and 8x perform identical? I'd expect 8x to perform way slower if it was running up against bandwidth limits.


It looks like NVidia's pipeline architecture doesn't allow both TMU's to be active when any form of anisotropic filtering is enabled. Kinda like the way trilinear kills the second texture unit on some architectures.