On Thu, 5 Dec 2002, magenta wrote: > > > > - FSAA _cannot_ be done by a wrapper. End of discussion. It needs driver > > explicit support for it. It's not a "select one default value when > > presented a choice" kind of passthrough thing. > > Why not?
Have you seen what the different FSAA cards can do? They have several different options for how to do the pattern for multisampling, and some cards seem to even allow fully programmable selection of the pixels. > I doubt the second one. Apparently my understanding of how FSAA is enabled > in an OpenGL application is flawed Yes. For one, you seem to think thatit's just a matterof selecting how many pixels to sample. That's not the multisampling that modern cards do, that's the old traditional (expensive and not as visually pleasing) regular anti-aliasing. > but from what I understand, on cards > which support it, it is enabled by adding an appropriate attribute to the > attribute list passed to glXChooseVisual. At least, that's what I've been > led to believe by every document I can find online. Sure, you can do it that way, but that means that you can never tweak the behaviour to what you really want. Because you won't be able to set the patterns etc. Thats' a fundamental limitation. While a hw-specific side band thing can be much simpler, simply because the (one) hw-specific setup program can _know_ what the hw limitations are. No need to try to describe them through some portable channel. (I personally suspect that _describing_ the settings is harder than then telling the card to use them. But that's the thing - if the app has to set the settings, then they first have to be described to the app in order for the app to know what it might be doing). > So please explain to me this: if the R100 driver does not support FSAA, but > the R100 hardware does support it, is this because the driver is missing > the functionality? How would FSAA be added to the R100 driver, if not by > implementing the multisample extension? I don't know about the R100, but I do know that the R200 does support proper multisampling. But I think it only supports a fixed pattern (different patterns at different sample sizes, I assume). The R300 is supposed to have programmable patterns. And no, as far as I can tell, none of the current drivers support any FSAA at all. I assume (not from knowing the cards, but just from trying to figure out what they do), that when you do 4-way multisampling, you have to make the buffer you render into be 4 times as wide (with a final "merge" blit at the end into the true picture and probably some special tiling too). That would definitely make it matter to the low-level driver a lot, even if it doesn't matter to the client itself. > Also, > the nVidia driver has an extension for hinting the sample pattern on top of > the ARB_multisample extension. Right. nVidia-specific, I bet. Do you want all apps to know about all the different vendor-specific stuff? Is that really a good idea for something that the app shouldn't even have to care about in the first place? > Right, but the purpose of a wrapper library would be to add the > application-configurable stuff into *every* application, rather than > putting a convoluted configuration interface into the driver. But the interfaces aren't convoluted if you can just let them be hw-specific. The code itself to _do_ the FSAA etc is convoluted enough on its own. It gets _more_ convoluted if it them also has to interact with overly generic channels in the driver. It's _easier_ to implement specific interfaces than generic ones. With your wrapper approach, you have multiple layers of translation, and that is sure as hell _more_ complicated than something that doesn't have the abstractions. Abstraction can be _bad_. Linus ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel