On 01.01.2010 23:32, Luca Barbieri wrote: > Currently Gallium defines a specific filtering mode for anisotropic > filtering. > > This however prevents proper implementation of > GL_EXT_texture_filter_anisotropic. > > The spec (written by nVidia) contains the following text: <<< A > texture's maximum degree of anisotropy is specified independent from > the texture's minification and magnification filter (as opposed to > being supported as an entirely new filtering mode). Implementations > are free to use the specified minification and magnification filter > to select a particular anisotropic texture filtering scheme. For > example, a NEAREST filter with a maximum degree of anisotropy of two > could be treated as a 2-tap filter that accounts for the direction of > anisotropy. Implementations are also permitted to ignore the > minification or magnification filter and implement the highest > quality of anisotropic filtering possible. > > and > > <<< Should there be a particular anisotropic texture filtering > minification and magnification mode? > > RESOLUTION: NO. The maximum degree of anisotropy should control > when anisotropic texturing is used. Making this orthogonal to the > minification and magnification filtering modes allows these settings > to influence the anisotropic scheme used. Yes, such an anisotropic > filtering scheme exists in hardware. > > Gallium does the opposite, and this prevents use of nearest > anisotropic filtering which is supported in nVidia hardware and also > introduces redundant state. > > This patch removes PIPE_TEX_FILTER_ANISO. Anisotropic filtering is > enabled if and only if max_anisotropy > 1.0. Values between 0.0 and > 1.0, inclusive, of max_anisotropy are to be considered equivalent, > and meaning to turn off anisotropic filtering. > > This approach has the small drawback of eliminating the possibility > of enabling anisotropic filter on either minification or > magnification separately, which Radeon hardware seems to support, is > currently support by Gallium but not exposed to OpenGL. If this is > actually useful it could be handled by splitting max_anisotropy in > two values and adding an appropriate OpenGL extension. > > How does Radeon anisotropic magnification differ from linear > magnification?
Note that different 3d apis have different requirements - ideally we should be able to choose some state which suits all of them. In particular, d3d10/11 have a separate filter mode for aniso (which applies to all of min/mag/mip filters at the same time). d3d9 also has special aniso filter, but it can be set separately for min and mag - apart from aniso d3d9 also has some more filters like 4-sample tent/guassian, all of them with undefined results if used as mip filter. max aniso values with d3d can be from (uint) 1 to 16, and I haven't seen hardware yet which could use float values for that. So it seems for conformant d3d9 (but not d3d10) implementation you'll need to be able to enable aniso for min/mag separately. Meanwhile, you said > This however prevents proper implementation of > GL_EXT_texture_filter_anisotropic. This isn't quite true - you've quoted it yourself "Implementations are also permitted to ignore the minification or magnification filter and implement the highest quality of anisotropic filtering possible." I don't think it's terribly useful to being able to enable anisotropic filtering with other min/mag filters, and d3d never allowed it hence hardware support for this will likely be rare. I don't really have a strong opinion though if we should allow this in the api or not, I guess it might make some drivers (except nvidia ones) (plus d3d state trackers...) a bit more complicated but it shouldn't be too bad, and maybe there's actually one app out there which would use it - or maybe it'll give better results for things like forced aniso. Roland ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
