On Thu, Dec 05, 2002 at 03:28:49PM -0800, Linus Torvalds wrote: | Let's put out some facts, instead of just arguing: | | - FSAA is a good idea...
Definitely. | - FSAA _cannot_ be done by a wrapper. End of discussion. Well, that depends on the hardware. Supersampled FSAA can be done without driver intervention or application awareness (Sun's SAGE is one example; in general, systems that can do video resize with filtering after the framebuffer will work). Multisampled FSAA is trickier because some information is lost, and some apps are affected by that. More memory in the framebuffer is also required. Other techniques exist but I don't have experience with them. I don't intend to argue for the wrapper approach, but a wrapper could use whatever out-of-band communication channel is available to talk to individual drivers and set up FSAA. For example, it could set the __GL_FSAA_MODE environment variable when talking to an NVIDIA driver, or on other systems alter the set of X11 Visuals advertised by the library so that the apps can only choose those for which FSAA is possible. It wouldn't be easy to get right, but it's probably possible. | But at the same time it is _not_ something that the actual client program | itself needs to care about. Usually not, though it can matter for apps that budget framebuffer memory very tightly (textures for games) or apps that expect precise color semantics (CAD apps that use object IDs encoded in colors for picking, or image compositing/editing apps that make critical demands on blending arithmetic). | ... 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?) Actually, the multisampling extensions for OpenGL provide some of that. It's needed for order-independent transparency and some multipass techniques. | Together they say to me "not wrapper, and not OpenGL extensions". In | short, they say "sideband information directly to the low-level driver". Sometimes you get lucky; anisotropic filtering is an example of a feature that's almost always harmless to enable without the app's knowledge. But for most things to work reliably, the app needs to be aware of what's going on. For example, turning on FSAA in a non-FSAA-aware game quite possibly could cause it to fail. The extra memory for the multisampling buffers can blow away the game's video memory budget. | 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. I disagree. Putting it in "kernel guy" terms, it's like sideband mechanisms for talking to device-dependent code in the kernel that bypass the syscall interface. A few such things exist for special purposes, but do you advocate using them as the normal way to make wholesale changes in the behavior of end-user apps? | And I don't think that FSAA is in any way special. There are tons of | examples of things like this... I think there are fewer useful ones than people realize, which is why I suggested earlier that dri-devel participants try to come up with a list. | 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. ... I believe it's a lot like the situation with themable toolkits. It's not necessarily sensible for every app to have explicit code to change its appearance, but it's not necessarily sensible for the appearance-changing code to go in Xlib, either. The right answer is for the functionality to be in the application, where the information needed to make tradeoffs is available, but also for us to help out by providing some higher-level utilities to offload the app developers. Allen ------------------------------------------------------- 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
