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? > 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. 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? > 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. > 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. :-) -- //========================================================\\ || D. Hageman <[EMAIL PROTECTED]> || \\========================================================// ------------------------------------------------------- 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
