On Thu, Dec 05, 2002 at 03:28:49PM -0800, Linus Torvalds wrote: > > On Thu, 5 Dec 2002, magenta wrote: > > > > > > Well that sucks. I guess I'd never be able to enable super-sampled FSAA > > > with your wrapper on my R100. Even though I CAN do it with a driver-based > > > tweak utility on some other operating system. > > > > But it's not even supported in the DRI driver on the R100... It's not like > > the wrapper can magically make functionality which isn't there to begin > > with appear, but in order to do the tweak in teh driver itself, the driver > > would have to support it anyway! > > Ok. Please listen to yourself for a moment, and then _think_ about this.
I have been doing both this whole time. > Let's put out some facts, instead of just arguing: > > - FSAA is a good idea, especially for games and eyecandy. Maybe the CAD > people don't care, but jaggies are horribly visible to the human eye, > and this is one reason why computer-generated graphics at high > resolution still often looks _more_ fake than a regular old NTSC > picture at some ridiculously low resolution. > > - 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? > I doubt anybody disputes these two basic premises. FSAA is a good thing I doubt the second one. Apparently my understanding of how FSAA is enabled in an OpenGL application is flawed, 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. 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? > (assuming the hardware is potent enough ;), and at the same time FSAA is > another example of something that needs support from the low-level driver > some way anyway (possibly only setting a register, I don't know). > > But at the same time it is _not_ something that the actual client program > itself needs to care about. It's a very hw-dependent thing (ie different > cards have very different approaches for things like sample selection), > and yet it's largely invisible from a programmatic standpoint at a higher > level. Except that everything I've seen leads me to believe that it's up to the application to tell the GL driver "Hey, give me 4x multisampling." Also, the nVidia driver has an extension for hinting the sample pattern on top of the ARB_multisample extension. Specifically I'm going based on this, and I was assuming that everyone else was as well: http://oss.sgi.com/projects/ogl-sample/registry/ARB/multisample.txt > And I would claim that these two issues are important: > > - intimate hw-dependency (ie it's literally _hard_ to have a generic > interface for it - do you really want to engineer some kind of OpenGL > system for letting apps be told what kinds of supersampling patterns > are available to be chosen?) Except that the ARB_multisample extension already provides the interface for saying that multisampling should happen, with the implication that the driver would choose a pretty good default pattern. > - invisible to the client (ie the client doesn't need to care about the > feature). And don't get me wrong: the client _can_ see the result of it > (hey, it could just read back the picture it wrote), I just mean that > the client doesn't really need to care or do anything special about it. Which is how the ARB_multisample extension appears to be written. > Together they say to me "not wrapper, and not OpenGL extensions". In > short, they say "sideband information directly to the low-level driver". > > I'm not even going to argue what the implementation for the side-band > information is - I don't think that is the most important part. But I > _will_ argue that it is clearly a good idea, and every _single_ argument > against it has been pure and utter cow-manure. Every argument I've made has been under the assumption that the sideband information would be configurable by a normal application to begin with. I'm not arguing against the ability to configure a driver directly, I'm just saying that the vast majority of what's been stated as configurable could just as easily be done by a wrapper library. > Are these things that can _also_ be done using regular GL interfaces? > Sure. You can do even things like supersampling pattern setup that way. > I'm not saying it is impossible for clients to set all these things by > hand. It's just that it's not necessarily _sensible_ to have the logic to > know about all these things in every program. And it's not a sin to have > two different ways to get to the same end result. 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. -- http://trikuare.cx ------------------------------------------------------- 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
