On Thu, Dec 05, 2002 at 02:15:10PM -0600, D. Hageman wrote: > On Thu, 5 Dec 2002, magenta wrote: > > > > > 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. > > > > Funny, that is what I usually imagine preloading libraries for ... > debugging. I mean, it is quite obviously available to be used for other > things, but I really do feel that it is exploiting a feature. I mean just > because the original VW beatle could float doesn't mean you should use it > as a boat ya know?
That is probably the worst damn analogy I've ever heard for this sort of discussion. I suppose you also think that a television should also only be used to watch broadcast shows. > > 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. > > I think you are predicting something that you can not. You can't claim > that the other solutions of environment variables or configuration files > would cause inconsistancies and random problems without having an > implementation demonstrated. Predicting the future is hard - people try > it all the time and they usually lose their ass in the stock market. You just love those bad analogies. Do the people losing their ass in the stock market try to use a VW Bug as a boat? > Another point ... do you know which platforms LD_PRELOAD works on and > which doesn't? Have you completely done your research on it? DRI at the > momment only supports a subset of the platforms out there, but it doesn't > do anything too radical that prevents it from being ported to most if not > all platforms ... how will this preloading runtime libraries effect that? But the very mechanism by which the DRI drivers are loaded pretty much guarantees that LD_PRELOAD will be available. And still, I'd rather see a simple wrapper library be supported on ALL OpenGL drivers for ALL platforms which support LD_PRELOAD than to see it limited to one or two DRI drivers (even if it's on all platforms which support 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. > > Again, you are making claims that you can not support. You have no proof > that the "added overhead, instability, and inconsistancy" would be cause > by the other solutions. Let us keep the FUD to a minimum please. I'm just speaking from experience in dealing with large software systems where decisions like this are added in post-hoc. > > Basically, I think the people who want this stuff included into the driver > > itself have lost sight of what "this stuff" is *for*. > > I don't think so ... don't think of it as being included in the driver as > that the driver looks at a common interface to determine how it should > render the data. If the interface is written correctly, then the code > wouldn't have to be recreated in each driver causing your so called > inconsistancies. I think we all know what we want, but getting there is > just going to have to take some friendly debate and in the end ... some > willingness to be flexible with the people that are doing most of the > work. :-) Why should the people doing "most of the work" (i.e. the DRI drivers) have to work on this other random thing too, when I could write a perfectly-functional wrapper library by myself in a relatively short time which would work with ALL OpenGL drivers under ALL UNIXes which support LD_PRELOAD? I'm not expecting "someone else" to write a wrapper library like this; what I'd hope is that by discussing the wrapper library, the DRI developers *wouldn't* end up spending a lot of time on implementing something which is, IMO, unnecessary. -- 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
