On Wed, Dec 04, 2002 at 12:18:03PM -0800, Ian Romanick wrote: > > 1. Users should be able to configure default behavior using configuration > > files (which would be selected based on argv[0] or similar) > > > > 2. Users should be able to configure default behavior using environment > > variables (which would be configured on a per-application basis using > > wrapper scripts or a launcher program or similar) > > > > 3. Users should not be able to configure default behavior; applications > > should specify all behavior explicitly if it matters, and expose this as an > > application-level configuration option to the user > > > > Personally, I'm torn between camps 1 and 3. > > In terms of policy, camps 1 and 2 really are the same. The difference > between 1 and 2 is just a matter of mechanism.
And yet the debate has been so heated! ;) > > Actually, I just thought of a solution which could possibly satisfy all > > three camps: have a libGL wrapper library (loaded via LD_PRELOAD) which > > overrides functionality as needed. Want to force FSAA to be enabled? Put > > it into glXCreateContext(). Want to force GL_RGB8 when the application > > chooses GL_RGB? Do it in glTexImage(). Hey, if you want to force GL_RGB4 > > when the application chooses GL_RGB8, you could do that too! > > > > Basically, I see no reason to put this configuration into the drivers > > themselves, as it could easily be done using an LD_PRELOADed library. > > I think that is not a good idea. We want to DISCOURAGE replacing / > modifying core libraries. Not only that, virtually all of the behavior that > has been discussed here is device-dependent. libGL.so is > device-independent. I don't really see a point in having a device-dependent > wrapper. That introduces the additional problem of having to have the > wrapper libGL.so and the *_dri.so in sync. I see only head-aches down that > path... But the whole thing behind the discussion is that this is about users tweaking behavior of games for quality/performance/etc., and this wouldn't replace libGL, it'd just supplement it. Like, libTweakGL or whatever. It's not card-specific functionality which is being talked about here, and I don't see why the functionality should go into the drivers. Like, for the purpose of *correctness*, yeah, the app should do things correctly to begin with (and not rely on undefined behavior). But that's not what the issue is, as I see it. The issue appears to be that some people want default behavior (hinting, internal texture quality, certain disabled-by-default extensions, etc.) to be configurable by the user, and people are proposing fixes which would needlessly complicate the individual drivers. My belief on this issue at this very moment is that libGL and the individual DRI drivers should favor correctness and quality over speed, and that external LD_PRELOADed tweak libraries should be used to override these default behaviors. It keeps the messy user configuration stuff out of DRI (keeping the drivers simpler and avoiding the headache of how to actually provide the configuration), it gives all of the functionality that the "empower the users" camp is rallying for, and it neatly solves all of the issues which have been talked about in this debate. The LD_PRELOAD mechanism is quite clean, and doesn't require any replacement or modification of core libraries (at least, not in the "replace your /usr/X11R6/lib/libGL.so.1.2 with this one and hope things don't break" way); it just allows the user to insert functionality which wasn't there before, like how the esddsp tool uses LD_PRELOAD to replace raw UNIX audio with esd calls, rather than requiring every application to move to libesd to work with esd. Some consider it "ugly," but personally I find it to be quite elegant. -- http://trikuare.cx ------------------------------------------------------- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
