State of the Graphics Industry Rant

[KimB]

Most blatant case: Texture with 1 bit alpha.

Just fyi, an alpha blend works just fine on those, on all hardware that I am aware of.

 

[Joe DeFuria]

. Few textures have any noticeable drawbacks that cannot be fixed by anisotropic filtering, or other better texture filtering methods.

"Few" textures? That's not "all" textures. And according to you guys, it seems it's either "all or nothing."

2. Those that do (Specifically, alpha tests or other per-pixel branching) can often be avoided entirely by using a smooth blend function. When that is not an option, it's not much of a challenge to do supersampling within the pixel shader. Not only that, but supersampling done within the pixel shader can definitely do a much better job than supersampling applied to the entire scene, and has much less performance hit.

Right....so if filtering techniques don't completely solve it...supersample it. That's what I said. (Supersampling within the shader or "globally" is irrelevant. )

For older hardware, the only truly noticeable drawback of MSAA lies in the use of an alpha test, which can usually be replaced by a simple alpha blend very easily.

Again..."only truly noticable"? "Usually be replaced?" Sorry. Any time the "math dictates" that AA should be applied and it isn't, means that multisample AA is not "correct" AA. If you have to "work around it" and do "special things" to avoid multisample AA pitfalls, that means by definition there are cases where it "fails." Read: not correct.

 

[RussSchultz]

You're right 1 bit alpha causes incorrect results. Best not to use it.

But seriously, that is the nature of the beast. It is well known that 1 bit alpha causes multisampling grief, so don't use the two together.

 

[Joe DeFuria]

You're right 1 bit alpha causes incorrect results. Best not to use it.

Exactly. And for Radeon aniso: "Best not to use textures that are anything but perfectly horizontal or vertical" too. That is the nature of the beast.

The point is, you have been pretty adament that the definition of an entire implementation being "not correct" is if it can be determined "where the math dictates" it should be applied, and it isn't. And no, I don't think it's "fair" to say "well, yes, the math dicatates it there, but it doesn't work...so just avoid putting yourself in that situation." (Do you think that's a valid exception to your definition?)

You quickly run into trouble with that definition, as the multisample illustration shows.

You can try and argue (as you essentially have), "Multisample AA 'by definition is not applied to those cases". Well, why isn't "Radeon 8500 Aniso", 'by definition', treated the same way?

"Anisotropic", like "antialias", is a generic, broad reaching term. Just as Mutisample, Fragment, Super, etc. are considered "valid forms of AA", I really don't see how "Radeon 8500" is not a "valid form of anisotropic."

 

[JF_Aidan_Pryde]

You guys really like discussing the past don't you?
Anyway, for future hardware, what kind of AA algorithm are they going to employ to fix the alpha problem when doing multisampling? Is there any algorithm that can detect ALLl edges correctly as well as correcly handle alpha textures? Z3 perhaps?

And other than brute supersampling, is there any other filtering methods that would reduce texture crawling? (Ansio doesn't quite cut it)

 

[darkblu]

excuse me for being quiet recently, i had to have some sleep.

I have problems with people who appear to disagree with me, while not having demonstrated they actually understand my viewpoint.

to have a problem with such things would be quite understandable. ..come to think of it, i could use this exact same wording to air my side in this dispute, don't you think, Joe? (1)

There is a difference there. (In other words...I'm not even CERTAIN if we disagree, because I'm not certain he's understood my view.)

see (1)

When I don't think someone actually understands my viewpoint, that's when I get all long-winded and repetitive. If I think someone does understand my viewpoint, and disagrees with it, then I have no problem just "agreeing to disagree."

good. i may take advantage of this good will of yours at a later stage.

When someone tells me that I'm having a "change of heart", etc, then I don't believe they understand my position. When someone asks more and more questions that to me have obvious answers if you do understand my position, then I don't think he understands my position.

sigh. at the time i used the phrase quoted here you had expressed a position of 'everything goes as long as the customer likes it'. then you used the 'green cube-red sphere' metaphore as an example of unacceptable inconsistency re visuals, which indeed contradicted your stance since how could you set any limits to what somebody could like - how do you know the customer would have not liked red speres over green cubes, despite that the latter were what the developer actually meant? so i though the phrase 'change of heart' was apt for the occasion, didn't mean to insult you. honestly.

When I think someone else is being inconsistent with their arguments, them I'm not satisfied that they understand my position.

quite an understandable grief.

On the contrary, I have already validated his. I have said several times that from a developer perspective, I can appreciate that "consistency across platforms" and "technical correctness" makes things much easier and is a highly desired trait.

yep.

On the other hand, it appears to me the he's been arguing that CONSUMERS also, on the whole, also desire/demand consistency and "correctness" over a choice of "compromise" methods that try to balance performance / quality / price.

nope.

my particularly argument with you, Joe, is that consumers have the right to see the visuals of the title they bought exactly as those visuals were meant to be seen by the title creators. afterwards, they could tweak on those visuals as much as they want, be that even through poking right into the card drivers if the consumer had the know how to do so, for the sake of getting higher fps, better comfort or just becasue they can, but that's only afterwards. otherwise, Joe, their 'contract' with the creator of the title is not fulfilled - they bought a car they never drove, if you will, and that basically, hurted them, unless, of course, they never meant to drive that car in the first place, but rather bought it to just use its engine for powering their home-made dragster.

i hope the above sheds some light on my early postings in this thread - that r200's aniso being flawed in a non-repairable way would not allow the r200 owners to see the visuals as those were meant to be seen in a title which relies on proper aniso, and that's regardless of the fact that the participants in this discussion may not be aware of any such particular title at the moment of the discussion.

hope that the above makes sense to the respective readers.

That's the crux over our "disagreement" IMO.

hope that now we cleared up that crux a bit.

ps to Russ:
thanks for sharing my point.

 

[Joe DeFuria]

to have a problem with such things would be quite understandable. ..come to think of it, i could use this exact same wording to air my side in this dispute, don't you think, Joe? (1)

Sure, I never said you couldn't. I'm not the one who accused anybody of "having a hard time" with someone who simply disagrees with you. That would be Russ.

at the time i used the phrase quoted here you had expressed a position of 'everything goes as long as the customer likes it'. then you used the 'green cube-red sphere' metaphore as an example of unacceptable inconsistency re visuals, which indeed contradicted your stance since how could you set any limits to what somebody could like

See, "you're not getting it" (my point) as far as I'm concerned. There is no contradiction. I explained it for you previously.

In explaining the apparent "contradiction", (paraphrasing...not going back through this thread to pick out the exact quote), if an IHV wants to render red spheres instead of green cubes....GREAT.

The consumers WILL DECIDE if that is an "acceptable translation" of the "developers will" if that's what you want to call it. The point is, IHVs will, ahead of time, "make to call" as to what they feel will be acceptable. I thought your "red cube" example was absurd...not because it crossed some "self drawn line of what's acceptable to be accurate or not." It's because how many IHVs do you think believe that is in fact acceptable?

As I said in a previous post, if an IHV really ln believes that rendering red, non textured cubes in place of Doom3 meshes "is what the consumers want", then I have no problem with that.

Good luck in selling those boards though.

my particularly argument with you, Joe, is that consumers have the right to see the visuals of the title they bought exactly as those visuals were meant to be seen by the title creators. afterwards, they could tweak on those visuals as much as they want, be that even through poking right into the card drivers if the consumer had the know how to do so, for the sake of getting higher fps, better comfort or just becasue they can, but that's only afterwards...

OK, we'll have to agree to disagree.

I'll state my main (but not only reason, for the sake of brevity). We'll also forget for the moment that I apparently disagree with your definition of a "contract" between the developer and consumer:

The right to see visuals in a "technically correct" way, competes directly with the right to see visuals with as much performance and as little cost as possible.

It is unfair for you to impose on IHVs that they MUST include options to see things "technically correct", because they impose additional costs.

Because these two consumer rights compete against one another, the one building the product has the right to decide how to balance them.

Joe, their 'contract' with the creator of the title is not fulfilled -

Might I remind you of what Carmack believes this 'contract' is. The contract is not 'correctness'. The contract is for the software is to 'be useful' to the consumer. For games, the use is "entertainment value." I do understand that you believe "technical quality" is intrinsic in this "entertainment value". I'm saying it's not, and certainly not whole of it. And IHVs should have the lattitude to draw that line where they want, and let the consumers decide if the hardware fulfills their need.

i hope the above sheds some light on my early postings in this thread - that r200's aniso being flawed in a non-repairable way would not allow the r200 owners to see the visuals as those were meant to be seen in a title which relies on proper aniso, and that's regardless of the fact that the participants in this discussion may not be aware of any such particular title at the moment of the discussion.

And I hope the above sheds light on my postings. That r200's aniso is not flawed, simply because it trades off speed for quality. That if ATI were forced to implement the so-called "technically correct" aniso, that could drive up the cost of the product, and/or eliminate the option of the "fast" version. Every IHV has the right to implement performance / quality trade-offs as he sees fit, and every consumer has the right to decide if the IHVs choice suits his own.

 

[RussSchultz]

The point is, you have been pretty adament that the definition of an entire implementation being "not correct" is if it can be determined "where the math dictates" it should be applied, and it isn't. And no, I don't think it's "fair" to say "well, yes, the math dicatates it there, but it doesn't work...so just avoid putting yourself in that situation." (Do you think that's a valid exception to your definition?)

You quickly run into trouble with that definition, as the multisample illustration shows.

You can try and argue (as you essentially have), "Multisample AA 'by definition is not applied to those cases". Well, why isn't "Radeon 8500 Aniso", 'by definition', treated the same way?

"Anisotropic", like "antialias", is a generic, broad reaching term. Just as Mutisample, Fragment, Super, etc. are considered "valid forms of AA", I really don't see how "Radeon 8500" is not a "valid form of anisotropic."

Quite simply:

The definition of anisotropic filtering is filtering in an anisotropic way. If you fail to do that when you're supposed to, you're not really doing anisotropic filtering when you're supposed to, are you? This is just like advertising 24 bit color, but only doing 7:7:7. Its what I call truth in advertising.

You obviously believe that there is some ambiguity in what anisotropic filtering is supposed to do and when it is supposed to do it; I obviously believe there is not.

As for multisampling, it does exactly what is advertised with a 1 bit alpha texture, its just that that result is not necessarily aesthetically pleasing. If anything, the 9700 automatically switching to supersampling for alpha textures is "wrong" (though aesthetically pleasing) because it produces unexpected results for somebody who asks for multisampling but doesn't get exactly that. (But yes, you're right, multisampling could be considered an "incorrect" method of filtering textures, but you don't use a hammer to drill holes now, do you?)

With each chip out there that does not perform exactly as advertised, the code paths grow and the developers are burdened more as they have to take into account all the work arounds. This is undesirable to the developers, but also to the consumers because they're stuck with shite games because there's too much work for the developers to adequately produce a quality piece of work.

And that is the last thing I have to say on the subject.

 

[Joe DeFuria]

As for multisampling, it does exactly what is advertised with a 1 bit alpha texture,

You mean, as for antialiasing it does exactly what it is suppossed to do with a 1 bit alpha texture?

You are conveniently changing the analogy I set forth.

Multisampling is NOT analogous to Anisotropic Filtering.

Antialiasing is analogous to Anisotropic Filtering. For example, I notice on nVidias control panels, there is ANTIALIASING settings. Not "multisampling" settings.

I repeat:

"Anisotropic", like "antialias", is a generic, broad reaching term. Just as Mutisample, Fragment, Super, etc. are considered "valid forms of AA", I really don't see how "Radeon 8500" is not a "valid form of anisotropic."

 

[Bjorn]

"Anisotropic", like "antialias", is a generic, broad reaching term. Just as Mutisample, Fragment, Super, etc. are considered "valid forms of AA", I really don't see how "Radeon 8500" is not a "valid form of anisotropic."

You answered this yourself imo.

Anisotropic , MSAA ... = broad reaching terms with known effects/drawbacks.
R8500 aniso = specific for one card with drawbacks specific for one card.

Doesn't that sort of disqualify the comparision right on the spot ( that you shouldn't treat them equally) ?

At least to me it does.

Btw, as you can guess, i'm completely on Russ side here.

 

[demalion]

On why the Radeon 8500 does not meet the spec (From the EXT_texture_filter_anisotropic extension):

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|.

Quite simply, if you rotate a primitive about the z-axis, Fx and Fy may well decrease (lower anisotropy used), while those derivatives should not be decreasing. The second condition is also probably not being met on off-angle surfaces.

From here:

3. How to Read an OpenGL Extension Specification

When reading an OpenGL extension specification, it helps to be familiar with the original OpenGL specification. The operation of an OpenGL extension is described as additions and changes to the core OpenGL specification. Having a copy of the core OpenGL specification handy is a good idea when reviewing an OpenGL specification.

OpenGL extension specifications consist of multiple sections. There is common form established by convention used by nearly all OpenGL extension specifications. Often within a specification, the gl and GL prefixes on routine names and tokens are assumed. The following describes the purpose of the most common sections in the order that they normally appear in extension specifications:

...
Overview

The section provides a description, often terse and without justification, for the extension’s specified functionality. If you are trying to figure out what the extension does, this is the most useful section of an OpenGL extension specification. Do not expect a tutorial though.

Issues

Often there are issues that need to be resolved in the specification of an extension. This section documents open issues and states the resolution to resolved issues. These issues are often things of interest to the extension implementer, but can also help a programmer understand how the extension really works.

From the OpenGL 1.3 PDF (neither the 1.3 PDF or the 1.4 PDF I looked at first have the word anisotropic in them, atleast that is what my search results tell me) Introduction:

1.5. OUR VIEW 3
1.5 Our View
We view OpenGL as a state machine that controls a set of specific drawing operations.
This model should engender a specification that satisfies the needs of both
programmers and implementors. It does not, however, necessarily provide a model
for implementation. An implementation must produce results conforming to those
produced by the specified methods, but there may be ways to carry out a particular
computation that are more efficient than the one specified.

From the Overview for that extension, copyright 1999 nVidia by the way:

Several approaches exist for improving texture sampling by accounting
for the anisotropic nature of the pixel filter footprint into texture
space. This extension provides a general mechanism for supporting
anisotropic texturing filtering schemes without specifying a
particular formulation of anisotropic filtering.

The extension permits the OpenGL application to specify on
a per-texture object basis the maximum degree of anisotropy to
account for in texture filtering.

Here, by the way, is an article on anisotropic texture filtering on the OpenGL.org site if you think your example this is more than just an extension specification, rather than some "universal OpenGL.org" specification.

So, what your example shows is that you begin to make a good case for the 8500 not meeting the standard for the GL_EXT_texture_filter_anisotropic extension (and no I'm not proposing that it isn't a valid extension because nVidia wrote it...it is accepted and that's that), atleast if you ignore or gloss over what OpenGL says these extensions are. Even if you succeeded in proving this, it would be the OpenGL definition of this anisotropic extension which OpenGL does not claim is the definitive and exclusive definition of anisotropic filtering... (but you could say that ATi's implementation of this extension is incorrect....if you could get away with making this case). But I don't believe you can even get away with making this case. Let us look at a "clincher" (IMO) here from nVidia's documentation on "Issues" in this extension, which I'm sure you just honestly "missed":

Should an implementation-defined limit for the maximum maximum degree of
anisotropy be "get-able"?

RESOLUTION: YES. But you should not assume that a high maximum
maximum degree of anisotropy implies anything about texture
filtering performance or quality.

I'm taking another break now, because the lengths and casualness exhibited by people I have reason to believe know better to flippantly waste my time with partial and dishonestly presented "evidence" has my blood boiling a bit again. I'm not blaming you for Chalnoth's text, Russ, but I foresee lots of mileage for time wasting here for him by forcing me to repeat and delineate every point of logic from this presented information and just "not seeing" my point, and I'll need a more even temper to handle that and continued discussion. To you again, Russ, please read the sections I refer to here if you thought his argument was valid.

 

[demalion]

"Anisotropic", like "antialias", is a generic, broad reaching term. Just as Mutisample, Fragment, Super, etc. are considered "valid forms of AA", I really don't see how "Radeon 8500" is not a "valid form of anisotropic."

You answered this yourself imo.

Anisotropic , MSAA ... = broad reaching terms with known effects/drawbacks.
R8500 aniso = specific for one card with drawbacks specific for one card.

Doesn't that sort of disqualify the comparision right on the spot ( that you shouldn't treat them equally) ?

It seems you are misquoting him, Bjorn. I read his statements like this:

"Anisotropic, FSAA... = broad reaching terms"

"R8500 aniso, MSAA = specific implementations with known effects drawbacks"

 

[RussSchultz]

An implementation must produce results conforming to those
produced by the specified methods

Or am I missing something?

Of course, thats in nearly direct opposition to:

But you should not assume that a high maximum
maximum degree of anisotropy implies anything about texture
filtering performance or quality

So, if you really want to call it not broken, I'll agree with you.

Then I'll say the quality of the filtering is poor in some cases, but I'm not going to agree that it is "ok" to exhibit such artifacts.

So, pick your poison. I'll definately not reply on this topic again.

 

[demalion]

An implementation must produce results conforming to those
produced by the specified methods

Or am I missing something?

Yes, you are...most of my text actually. but let us atleast add the sentence before, and the rest of the sentence for now:

It does not, however, necessarily provide a model
for implementation. An implementation must produce results conforming to those produced by the specified methods, but there may be ways to carry out a particular computation that are more efficient than the one specified.

Of course, thats in nearly direct opposition to:

But you should not assume that a high maximum
maximum degree of anisotropy implies anything about texture
filtering performance or quality

No, not if you read the text provided about how to read the specification of the extension, and re-read how the OpenGL specification doesn't mention the word "anisotropic" anywhere in either the 1.3 or 1.4 PDF files (is the "Find" function in acrobat reader reliable? I presume so, seems to work for other words).

So, if you really want to call it not broken, I'll agree with you.

I haven't said anything new, it was just a matter of further illustration. As incomplete as Chalnoth's info was, atleast it move us forward enough for this.

I'm struck that the rest of your text wasn't in dispute, yet you present it as if it was. I presume I can just state "objective" and "subjective" and their application is evident here? I'm going to re-write your text the way I read it to illustrate what exactly I view was never in dispute:

"Then I'll say the quality of the filtering is poor in some cases, but I'm not going to agree that it is "ok" to me to exhibit such artifacts."

 

[Bjorn]

It seems you are misquoting him, Bjorn. I read his statements like this:

"Anisotropic, FSAA... = broad reaching terms"

"R8500 aniso, MSAA = specific implementations with known effects drawbacks"

Here's what Joe said:

"Anisotropic", like "antialias", is a generic, broad reaching term. Just as Mutisample, Fragment, Super, etc. are considered "valid forms of AA", I really don't see how "Radeon 8500" is not a "valid form of anisotropic."

Multisample, Fragment & Super is still not vendor specific.

But "R 8500 anisotropic filtering" clearly are.

 

[demalion]

It seems you are misquoting him, Bjorn. I read his statements like this:

"Anisotropic, FSAA... = broad reaching terms"

"R8500 aniso, MSAA = specific implementations with known effects drawbacks"

Here's what Joe said:

"Anisotropic", like "antialias", is a generic, broad reaching term. Just as Mutisample, Fragment, Super, etc. are considered "valid forms of AA", I really don't see how "Radeon 8500" is not a "valid form of anisotropic."

I read it again and don't see how you are getting your phrasing and not mine. Why is it significant that the 8500 aniso is called 8500 aniso, or that it is vendor specific? Would it change things if we had a technical sounding name for it that didn't mention the 8500? Does it help that it is also on the "7x00" Radeons? Would using rip-mapping as an example instead satisfy you? Your distinction seems meaningless at this point.

Multisample, Fragment & Super is still broad reaching terms with no vendor specific details imo.

But "R 8500 anisotropic filtering" clearly are.

So? I'm serious, why is something vendor specific necessarily "incorrect" simply because it is vendor specific? I don't get your point with that at all. I am still pretty sure, regardless, that what Joe is saying is intended to fit my phrasing, perhaps he will comment...if you want to re-phrase it, please provide justification?

 

[Bjorn]

So? I'm serious, why is something vendor specific necessarily "incorrect" simply because it is vendor specific?

I didn't say that something that was vendor specific necessarily was incorrect did i ?

But the R8500's aniso filtering is clearly incorrect in 45 degree angles.
A problem that only Ati's card has. Thus, it's a vendor specific problem.

There's afaik no other card that has a problem like that with anis filtering.
Difference in quality yes, but in this case we're talking about no aniso at all sometimes.

I agree though, that i misread what Joe said.

But i'd then disagree (of course ) with him since i don't consider MSAA , Supersample and FAA to be nearly as "hardcoded" as one specific vendors implementation of anisotropic filtering.

Edit:

I don't consider the R8500 aniso to be broken. Technically, i would say, yes it's broken. But as a user, no, just flawed. This was also what this discussion started about.
Is it flawed or not ?

And again i say yes, i think it is.

Now, would i still want an option for that kind of aniso with close to 0% performance loss for my GF4 ? Yep.

 

[demalion]

So? I'm serious, why is something vendor specific necessarily "incorrect" simply because it is vendor specific?

I didn't say that something that was vendor specific necessarily was incorrect did i ?

But the R8500's aniso filtering is clearly incorrect in 45 degree angles.
A problem that only Ati's card has. Thus, it's a vendor specific problem.

I consider your statement "clearly incorrect" to be blatantly subjective and unsupported, see the past 4 pages...maybe even more. It is slightly frustrating to me for you to make that statement after ignoring all those pages of discussion.

Ignoring that for the moment:

While Radeon cards didn't support multisampling, wouldn't this apply to nVidia multisampling and its drawbacks?

Ignoring that, I repeat a question:

What about rip-mapping?

There's afaik no other card that has a problem like that.

There is the set of implementations and there is the set of implementations found in graphics cards. I view one as pertinent to this issue, and the other as not. If you view that other (the latter of the two) as pertinent, please provide your justification?

Difference in quality yes, but in this case we're talking about no aniso at all sometimes.

Which is a statment that fits perfectly with MSAA, but you keep throwing in "vendor specific" as if the justification of the association is self-evident...

I agree though, that i misread what Joe said.

This is pretty rapid progress for the track record of this thread.

And i'd then disagree with him since i don't consider MSAA , Supersample and FAA to be nearly as "hardcoded" as one specific vendors implementation of anisotropic filtering.

Atleast your disagreement is on a clearer track now, I think, though the justification for it seems to be missing right now. Just to be clear, this is not a dispute as to what you consider for your own preference, but a dispute about what can be used to objectively state that the Radeon (<9500) method of anisotropic filtering is "incorrect".

 

[Bjorn]

I read it again and don't see how you are getting your phrasing and not mine. Why is it significant that the 8500 aniso is called 8500 aniso, or that it is vendor specific? Would it change things if we had a technical sounding name for it that didn't mention the 8500? Does it help that it is also on the "7x00" Radeons? Would using rip-mapping as an example instead satisfy you? Your distinction seems meaningless at this point.

The name has of course nothing to do with it.
But i consider f.e MSAA and Supersampling to be different methods of achieving AA, none of them connected to a specific vendor.
But the aniso of the R8500 and it's drawbacks/flaws are a vendor specific implementation of one specific method of filtering, anisotropic.
That's the difference imo.

 

[demalion]

I read it again and don't see how you are getting your phrasing and not mine. Why is it significant that the 8500 aniso is called 8500 aniso, or that it is vendor specific? Would it change things if we had a technical sounding name for it that didn't mention the 8500? Does it help that it is also on the "7x00" Radeons? Would using rip-mapping as an example instead satisfy you? Your distinction seems meaningless at this point.

The name has of course nothing to do with it.
But i consider f.e MSAA and Supersampling to be different methods of achieving AA, none of them connected to a specific vendor.
But the aniso of the R8500 and it's drawbacks/flaws are a vendor specific implementation of one specific method of filtering, anisotropic.
That's the difference imo.

I understand that is a difference.

I do not understand how it is the difference that justifies the viewpoint that the 8500 aniso method is objectively "incorrect".