I want to know where radar gets the Anisotropic specification from.
NVIDIA Are the Industry Standard Shader Driving Force?
- Thread starter Dave Baumann
- Start date
radar1200gs
Regular
Unit01 said:Yeah that's why Nv touted their own adaptive anisotropic filtrering for their FX5800 launch as being better and faster than the competition. And according to you, adaptive anisotropic filtrering isn't real AF. So what does the FX series do then?radar1200gs said:
Are you going to do as you did on anandtech and say that the 3dmark03 thing isn't a cheat and it's a conspiracy between MS and FM and ATI
Detonators been cheating a long time. Check the old Radeon vs GF2GTS review at hardocp. Where nvidia lowers detail for higher performance. But then again, that can't be true. Must be a conspiracy between ID and [H]
Yes, the GF-FX does allow for adaptive (partial) anisotropic filtering. However, the full blown, proper anisotropic filtering method is present and selectable in every single driver released since the GF-FX. It is the users choice which variety of Anisotropic filtering they will use. R200 owners get no choice.
As for the definition of anisotropic filtering, extreme tech did a resonable article. nVidias full blown anisotropic filtering is (I believe without searching) based upon SGI anisotropic filtering.
EDIT: Regarding David Kirks comments of ATi filtering, I'm fairly certain they were prompted by ATi claiming their Anisotropic filtering would be superior to that of nVidia's at the time of R200's release. I remember an article in a local (australian) magazine talking about ATi's next gen cards and anisotropic filtering at the time, so it's entirely possible David Kirk was actually addressing claims made by ATi and not merely criticizing ATi just becuase he could. I might try and hunt the magazine down sometime.
radar1200gs said:
I may be missing something, but what does R200 have to do with nv3x by way of comparison?
Heh...lots of things in all current 3D environments are "based on" something or other that came out of SGI....
I'm hoping that you understand that your GF3 isn't using the same drivers that an nV3x product uses, even though you use the same "unified" Detonator driver release. From other things you've said I'm not sure if you're entirely clear on that. IE, you cannot postulate nV3x driver characteristics based on your GF3 experience with the same Detonator release.
radar1200gs
Regular
I don't yet have a GF-FX of my own (waiting for the damned 5600U to arrive in Australia), but, from everything I've read online, setting anisotropic manually in the drivers on the Application (or Quality or whatever they are currently calling it this version) will yield identical filtering to a GF4 or GF3 set the same.
radar1200gs said:
Well, I was talking about the "3DMurk" thing uncovered at TR, as an example, which I believe we discussed briefly in another thread. You won't see a performance difference with the GF3, but may see one with your 5600U, however, with the same Det release (different drivers within the unified set.) I think TR tested with an nv30, though.
radar1200gs
Regular
Unit01 said:
You are wrong. NV3x is capable of both adaptive and full blown anisotropic filtering.
The adaptive side of things was based directly on DirectX9 specifications - it exploits multisampling - the lower quality modes read less samples and use bilinear instead of trilinear at the low end. The multisampling part of DX9 was buggy to begin with however, which is why Microsoft released DX9.0a
R200 only uses bilinear sampling, not trilinear when applying "anisotropic" filtering. The SGI method used by nVidia requires trilinear samples throughout. it also requires the filtering to work at all angles, not just a select few.
Wrong. DX9 and multisampling has nothing to do with how they implement Anistropic filtering.
All modes of Anisotropic filtering are 'adaptive' on all NV/ATi boards that utilise it since that the only sane way of doing things - when they say adaptive they mean it will only take the maximum number or samples dependant on the angle (in relation to the viewport) that the testure is at. i.e. there is no point takeing more sample if the texture being sampled is parallel with the view port. Bi or Trilinear filtering at vertain parts have nothing to do with this.
Oh, and please go and find this specification that "defines" anisotropic filtering...
radar1200gs said:
Possibly, and from a performance standpoint ATi were right, it was superior. Agreed you couldn't use trilinear with aniso, and the angles it didn't apply AF to were more widespread than on the R3x0 cards, but it still took a very small performance hit compared to the NV2x cards, which meant that it was the first aniso implementation that you could actually use in all games without framerates suffering terribly as a result.
Not to drag this back up again, but I do think its non-intuitive to claim to support a max-anisotropy of 8, but only function to a degree of 2 when requested to do 8.DaveBaumann said:
I won't claim "wrong" or "incorrect" to avoid the wrath that is Demalion, but its not right in my book.
The fact that it is termed as max anisotropy of 8 degree's would imply that it not always doing 8. i.e. "the maximum I will do is 8, but I'll do less where its not required to do the maximum".
radar1200gs
Regular
If you are talking OpenGL V1.2, nVidia themselves provide the definition
http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_filter_anisotropic.txt
based on SGI work
http://www.sgi.com/software/performer/brew/pdfs/anisotropic.pdf
http://www.nvnews.net/previews/geforce4/page_3.shtml
Regarding the DX9 implementation, the idea was that when using MSAA you automatically generated extra sampling points (because of the way MSAA works) which could be used for Anisotropic filtering inputs as well as for antialiasing.
Sadly none of this is spelled out in the release SDK, but i am sure it was in the beta SDK, a copy of which I didn't keep (funny how the DX9 documentation fell in a heap just prior to the DX9 cheif defecting to ATi to work on their drivers...)
http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_filter_anisotropic.txt
based on SGI work
http://www.sgi.com/software/performer/brew/pdfs/anisotropic.pdf
http://www.nvnews.net/previews/geforce4/page_3.shtml
Regarding the DX9 implementation, the idea was that when using MSAA you automatically generated extra sampling points (because of the way MSAA works) which could be used for Anisotropic filtering inputs as well as for antialiasing.
Sadly none of this is spelled out in the release SDK, but i am sure it was in the beta SDK, a copy of which I didn't keep (funny how the DX9 documentation fell in a heap just prior to the DX9 cheif defecting to ATi to work on their drivers...)
Sure, but its not doing 8 in some cases when its "required to". Its only doing ~2.DaveBaumann said:
If the drivers reported 8, but only did that on say one pixel and did 2x on the rest of the pixels, is that still ok?
radar1200gs said:
Read that PDF - that isn't actually Anisotropic filtering, that an approximation of Anisotropic filtering termed as RIP mapping (coincidentally, this is what many people actually thought R200 was doing). Mike has incorrectly linked to that article - this isn't actually the type of Anisotropic filtering that NV2x/3x or ATI are doing; thats based on a sort of prefiltered/mip maps level method which is not what modern graphics chips are doing, since they are actually doing the filtering on the fly.
radar1200gs said:
MSAA doesn't doing anything with texturing, thats part of the point. MSAA and Anisotropic filtering are intrinsically different things. IT would be nonsenical to link them together as well seeing as they are not necessarily tied together.
radar1200gs said:
Phil Taylor doesn;t work on ATI's drivers. And I've certianly not seen any mention of things like this either. Back it up.
RussSchultz said:
Eh, Russ, are you talking about the filtering pattern difference between ATI and NV boards when texturing a 'tube' (a la SamX's filtering test)? Becuase if so, I don't think thats what is mean to be referred to when talking about adaptive. I think adaptive in this context is the angle that the texture is displayed at. i.e. let assume you had a surface to texture that was running parallel with the top and bottom of the viewport - if the Z values of the top and bottom of the surface were the same then there would be no requirement to do any extra texture sampling; if the z values of the top and bottom of the surfce to be textured had quite a variance (and the y values didn't - such as that of a flat floor of an FPS) then you would need to sample more. That what I take 'adpative' to mean, the other thing is a shortcut for performance.
Yeah, was talking about the off angle thingie dingie.
Of topic, a bit: I think if you've got a wide angle of view (think fisheye), you could have a plane perpendicular to the Z axis in front of you that requires more sampling on the outer reaches of the screen, even though the depth never changes.
I think anyways.
Not sure how either hardware would deal with such a situation.
Of topic, a bit: I think if you've got a wide angle of view (think fisheye), you could have a plane perpendicular to the Z axis in front of you that requires more sampling on the outer reaches of the screen, even though the depth never changes.
I think anyways.
Not sure how either hardware would deal with such a situation.
radar1200gs said:
Seriously radar, lots and lots of common things in *all* current 3D environments today are "based on" principles originated by SGI. It's hardly a "claim to fame" by any single company, since they all share those principles. Yes, that means ATi, too. It also meant 3dfx, and all the rest. While it might sound cool, it really means very little when comparing one 3D chip company to another. In a sense it's like saying that current land-line telephone service is "based on" work pioneered by Bell telephone--two tin cans tied together with a taut piece of string...
Doomtrooper
Veteran
This thread hurts my brain, it is bad enough when arm chair experts troll the fan sites, but when they try to talk 'techno' on probably the most advanced forum for 3D graphics on the net, it is down right laughable
Doomtrooper said:This thread hurts my brain, it is bad enough when arm chair experts troll the fan sites, but when they try to talk 'techno' on probably the most advanced forum for 3D graphics on the net, it is down right laughable
I'll second that. I especially loved the part about doing AF through MSAA...
While learning a few techno-babble buzzwords and randomly throwing them around to look like you know what you are talking about ("What is great with IHV X's Anisotropic Antialiasing is the T&L Shader Precision Mapping implementation which brings 4 times the performance for the same quality, making real-time Wireframe Shadowing through Per-pixel Stencil Occlusion a possibility for the first time") may bring you a long way in many forums, someone with a clue (even a very small one) would have guessed by now that it's not possible in the B3D forums...
Similar threads
