On Thu, Dec 05, 2002 at 10:22:39AM -0800, Ian Romanick wrote: > On Wed, Dec 04, 2002 at 03:52:39PM -0800, magenta wrote: > > On Wed, Dec 04, 2002 at 02:21:30PM -0800, Ian Romanick wrote: > > > > > > As far as I can tell, there is no way either an app or a wrapper library > > > could communicate this information to the driver. Yet, shipping "high end" > > > drivers support and demanding users expect this level of > > > application-to-driver tuning. > > > > A wrapper library doesn't have to communicate any information to the driver > > - it just intercepts the function calls and turns them into something based > > on the user's preference. > > I completely understand how the wrapper idea works. I'm just saying that > there is a large number of demonstrably interesting cases that the wrapper > cannot possibly support...
But it's just for making little configuration tweaks. A glEnable() at the context creation if it's something that the app doesn't know about, sending GL_RGB8 when the app only sends GL_RGB, that sort of thing. You know, overriding the *default* behavior of OpenGL for the times when a user wants it to be overridden. > > Or, for a more complex idea, let's say the user wants to force wireframe > > rendering and FSAA. Probably the easiest way for this to happen is for the > > wrapper library to have something like: > > ...and this is one of them. There is NO OpenGL extension for super-sampling > style FSAA (the only kind that most cards support). Given that, there is > NOTHING that the wrapper library could possibly do to silently promote > regular visuals to FSAA visuals. They could, in glXChooseVisual. > There's enough cases that the wrapper couldn't cover that we'd have to > implement something in the driver anyway. For example, one of the current > env vars tells the Radeon driver to not use HW TCL. How could the wrapper > do that? That's not what the wrapper would be for. It'd be for adding quality tweaks (you know, like the whole original point to the post which started this discussion, about defaulting to GL_RGB8 all the time), not driver debugging (or replacing the current driver debug mechanism, namely environment variables). Driver debugging should stay the way it is. I'd just rather see a wrapper library for *quality tweaks* than a whole mess of environment variables which add bloat and weird edge cases to the drivers themselves. Also, a wrapper library would be consistent across *all* drivers on *all* OpenGL implementations, rather than being specifically for, say, a Radeon running DRI. Also, the intent isn't to make the wrapper library "something which everyone runs." Only people who want to run it would run it. It's not a replacement to libGL, it's just something for tweaking quality, when people want the quality to be tweaked. Which is another thing in its favor - users who don't give a damn wouldn't be subjected to the added overhead, instability, and inconsistency which putting it into the driver itself would cause. Basically, I think the people who want this stuff included into the driver itself have lost sight of what "this stuff" is *for*. -- 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
