From: magenta <ma...@tr...> - 2002-12-06 01:40:56
|
On Thu, Dec 05, 2002 at 04:57:06PM -0800, Linus Torvalds wrote: > > > 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 the wrapper library would have access to everything that the individual applications have access to. If an application can set that stuff up, so can a wrapper library (henceforth written IAACSTSUSCAWL). > > 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. Right, but if you just want to enable naive multisampling or FSAA (which I personally see as a special case of multisampling, where the multisample buffer just happens to cover the entire screen) or whatever, and just want to do it in a quick tweak to make Tuxracer look better, then the wrapper library can just enable it in the way that Tuxracer would. IAACSTSUSCAWL. > 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. Yes, and the hw-specific side band would either have to be configured by the user for the entire driver (bad, for reasons which have been espoused at length) or by the application, and IAACSTSUSCAWL. > > 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. Right, but if the client just says, "Hey, make this buffer 4x supersampled" and lets the driver deal with that at blit-time, then it can be easily configured by the application through an extension. And IAACSTSUSCAWL. > > 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 wrapper library could be extended to support vendor-specific extensions. IAACSTSUSCAWL. > > 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. Yes, exactly, and the application can be made aware of those interfaces. And IAACSTSUSCAWL. > 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. That depends. Is the driver doing the FSAA etc., as configured by the user or the application, or is the application itself doing the FSAA? Most likely it's the first one. And if there's an interface for the application to configure the driver for doing FSAA, well, you know the rest... > Abstraction can be _bad_. But so can requiring every single application to specifically support every single vendor-specific extension. -- http://trikuare.cx |