State of the Graphics Industry Rant

[Joe DeFuria]

Thank you, Joe, for leaving off the next sentence which essentially said exactly what you did.

Sigh...

Since texture rotation had nothing to do with internal formatting of DXTC, I thought it would be "OK" to leave that off.

But to make you happy, I'll "add the next sentence" and make it relevant for you.

"At that point, I'll have to say their implementation sucked, since it failed to deliver as high a quality result as competitor's did."

 

[RussSchultz]

Like I said Joe, you and I aren't saying anything different.

 

[darkblu]

You are also using reviewers opinions who chose to use the 'word fixed' vs. improved upon... ATI improved their adaptive algorythm to adress these minor issues, the same can't be said about texture compression as it still isn't Fixed. In 99% of the General use the Radeon 8500's implemention did not effect image quality, actually improved it...

please, spare us both the gf texture compression issues counter-point - i'm not an nvidia fan. we're talking stricktly whether an implementation of a graphics feature*, which by definition is supposed to work under any condition but in a particualr implementation fails under the condition X, is flowed or not. it just happens so that this thing is 8500's aniso.

so, 8500's algorithm failed under circumstances an aniso filtering algorithm is supposed to work, and the casual word for such a misbehaviour is flowed. hence, it got fixed.

* not in the sense of a product feature but in the sense of a feature defined, loosely as it may be, in the APIs.

 

[Dave Baumann]

The way the 9700 fits into this seems to be confusing the issue.

There two elements of difference here:

8500 only does bilinear + aniso; 9700 does bi and trilinear + Aniso.

8500 has trouble when rotating around the z axis; 9700 does not.

Is there any basis for saying from what 9700 can do that 8500's implemtation was 'broken'? No, because they are different implementations - we all know that 8500 can only do bilinear with aniso but just because 9700 doesn't have that limitation is not a basis for saying 8500 is broken.

 

[RussSchultz]

Thank you, Joe, for leaving off the next sentence which essentially said exactly what you did.

Sigh...

Since texture rotation had nothing to do with internal formatting of DXTC, I thought it would be "OK" to leave that off.

But to make you happy, I'll "add the next sentence" and make it relevant for you.

"At that point, I'll have to say their implementation sucked, since it failed to deliver as high a quality result as competitor's did."

You still got the wrong sentence:

To do it in 16 bit space is just as 'valid' an interpretation as to do it in 24 bit space. One obviously has better output, however.

 

[RussSchultz]

and the casual word for such a misbehaviour is flowed

Umm, actually the word is flawed. With an A.

(Sorry to be nitpicky. You just repeated it twice in two separate posts)

 

[darkblu]

and the casual word for such a misbehaviour is flowed

Umm, actually the word is flawed. With an A.

(Sorry to be nitpicky. You just repeated it twice in two separate posts)

mea culpa, thanks for the correction, Russ

 

[Joe DeFuria]

Russ,

Actully, I don't think you are saying the same thing.

And the only reason why I'm "picking" on you, is because at the same time you're arguing, you decided to pulling the "f@nboy" argument on Doom.

IMO...you and doom are doing the same thing. Downplaying the "disadvantages" of "your companies" product, and going "over the top" on the disadvantages of the "other" companies product.

Example:

You on S3TC issue: "One obviously has better output, however."

You on ATI Aniso Issue: "At that point, I'll have to say their implementation sucked..."

Now, I am saying something different. I am saying that I don't see any case of suckage. I see cases of trade-offs being made, with advantages and disadvantages in either cost, quality and/or performance.

My attempt to get you to see your statements as inflamatory (by throwing your "implementation sucked") words back at you apparently failed. Though by your reaction to it, you obviously agree that it IS inflamatory.

And you wonder why "tensions rise" in here...

 

[Dave Baumann]

I am saying that I don't see any case of suckage. I see cases of trade-offs being made, with advantages and disadvantages in either cost, quality and/or performance.

In that instance though, what was the trade off with DXT1? With 8500's aniso the trade off was quality for speed; with DXT1 was there any speed to be gained by not interpolating it to 32bit when everything occurs internally?

 

[Joe DeFuria]

In that instance though, what was the trade off with DXT1?

I presume the trade-off was cost. It cost nvidia less to implement it with 16 bit interpolation vs. 32 bit.

 

[darkblu]

There two elements of difference here:

8500 only does bilinear + aniso; 9700 does bi and trilinear + Aniso.

8500 has trouble when rotating around the z axis; 9700 does not.

Is there any basis for saying from what 9700 can do that 8500's implemtation was 'broken'? No, because they are different implementations - we all know that 8500 can only do bilinear with aniso but just because 9700 doesn't have that limitation is not a basis for saying 8500 is broken.

funny, Dave, you enumerate two (2) elements but you draw you '8500's aniso is not broken' conclusion only based on the first. check the other thing, too.

 

[Dave Baumann]

funny, Dave, you enumerate two (2) elements but you draw you '8500's aniso is not broken' conclusion only based on the first. check the other thing, too.

that was the point of what I was getting at - there appears to have already been the conclusion that the z rotation limiation was a 'bug' becuase it has been 'fixed' in 9700 however how can you conclude its a 'bug' based on a new implemtation? Are we to conclude that the bilinear limitation was also a 'bug' because its 'fixed' in 9700?

I don't think there is any basis for saying that this wasn;t a pure design limitation for 8500 based on what 9700 is able to do. This is also why I say that a far better comparison to make is between 9000 and 8500 - if it was a 'bug' then it would be more likely that they would have fixed it there; if it was an implementation limitation then its less likely they woulkd have risked a known and operable design to change it.

 

[Doomtrooper]

so, 8500's algorithm failed under circumstances an aniso filtering algorithm is supposed to work, and the casual word for such a misbehaviour is flowed. hence, it got fixed.

* not in the sense of a product feature but in the sense of a feature defined, loosely as it may be, in the APIs.

What are you calling a failure here ?? Rotating around the Z-Axis which is only seen in a flight sim in tail spin crashing towards the ground, then I also consider the Anistropic on Nvidia card to be a failure for alot of reasons:

1) Its total filtering is inferior

2)Its performance hit is too great..which forces you to lower the level of filtering which in turn affects the image quality.

There is positives and negetives on any implementation but I consider

1)Peformance
2)Overall Image quality
3)Requires 3rd party tweaker for D3D

A flaw in the implementation of Nvidia cards, and the only flaw I see in ATI's implemtation is the z-axis issue which is blown way out of context, and the people that are complaining never even tried or seen it in action

I'd like to point out Nvidia fan site Senior Editor Matt Burris reviewed the Optimus EXP 8500...this is what he had to say:

Very fast 3D performance
Anisotropic filtering looks good and has great performance

http://www.3dgpu.com/reviews/unitechr8500_6.php

 

[KimB]

I presume the trade-off was cost. It cost nvidia less to implement it with 16 bit interpolation vs. 32 bit.

Now that it's migrated to this topic, I'd just like to say that I really don't understand why this issue hasn't been fixed yet on GeForce cards.

In particular, DXT3 uses the exact same compression as DXT1, except that it also has an alpha channel. For some reason (probably so that the textures would be smaller in cache), nVidia chose to interpolate DXT1 in 16-bit, and DXT3 in 32-bit. There is absolutely no reason at all why the hardware, even the original GeForce1, cannot do 32-bit interpolation on DXT1. In fact, you would think that it would be less expensive in transistor-space, as DXT3 already uses 32-bit interpolation, why not just use those same transistors for DXT1?

As to the exact problems with DXT1 on a GeForce4, since the GeForce4 actually does dithering in texture space, it looks good for pretty much any texture that is minified, but has severe problems for smooth-gradient textures that are magnified. Fortunately, I was able to replace such textures in UT with palletized textures without removing high-res compressed textures.

Regardless, I'm really hoping that the NV30 will finally use 32-bit interpolation.

 

[John Reynolds]

I presume the trade-off was cost. It cost nvidia less to implement it with 16 bit interpolation vs. 32 bit.

I remember when games started shipping with TC enabled by default. Boy, did that change fast.

Doom:

Matt Burris is Senior Editor at 3DGPU, not site owner. But the point of your quote still stands.

 

[Doomtrooper]

please, spare us both the gf texture compression issues counter-point - i'm not an nvidia fan. we're talking stricktly whether an implementation of a graphics feature*, which by definition is supposed to work under any condition but in a particualr implementation fails under the condition X, is flowed or not. it just happens so that this thing is 8500's aniso.

Texture compression falls into that category too...sorry.

 

[KimB]

1) Its total filtering is inferior

I went ahead and looked at that review. The images were labeled:

1. Radeon 8500 Highest-quality aniso
2. Radeon 8500 High-quality aniso
3. GeForce3 aniso

There was a total lack of clarity on the GeForce3 anisotropic picture. It seems to me that that that pic could easily have just been using 2-degree aniso (While, I believe, the high-quality for the 8500 would be using around 8-degree...).

Regardless, this is the only picture I've ever seen where the GeForce3 was protrayed as looking significantly worse.

 

[Doomtrooper]

Regardless,

The only people I always see complaining about the 8500's anisotropic filtering are people that have not actually seen it, used it, played with it.

 

[breez]

why do the 9700@16x and the geforce4@8x result in identical test patterns ?

There is a visible difference, but it's not that big and it can't be seen when playing game.

 

[Matt Burris]

Thanks for correcting John. FWIW, both me and Brian own the site, half/half. As for the quote, I still stand by it, the 3D performance is fast, and whether or not the implementation of ATI's anisotropic filtering on the R8500 was flawed or not, as a gamer, it was just fine with me. Before I tried it out, I was skeptical and didn't like the sound of it, but I was corrected when I saw it firsthand in the games I play. For most gamers, it'll be just fine, and it looks good enough most of the time anyways. The only gamers who wouldn't like it probably would be flight simmers, where the angle of textures are constantly shifting. I'll just leave it to you guys to hash out this broken or not issue, but for most gamers, the issue is irrelevant.