On Thu, Dec 05, 2002 at 11:10:56AM -0800, magenta wrote:
> On Thu, Dec 05, 2002 at 10:22:39AM -0800, Ian Romanick wrote:
> > 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.
If that's all the greater scope that you want, then fine. However, I see no
reason to artificially limit ourselves. Afterall, the whole point of this
exercise is to remove artificial limits on functionality.
> > > 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.
No, you don't understand. There does not exist a GLX visual for
super-sampled FSAA. Given that there is no such visual, there is nothing
that a wrapper library could do in glXChooseVisual. Look at the extension
registry again. The ONLY extensions that support FSAA is
GL_{ARB,SGIS,3DFX}_multisample. As far as I know, there is NO hardware
supported by DRI that is capable of supporting these extensions (except the
later 3dfx hardware, of course). AFAIK, only NV20 and R300 support
multisampling.
> > 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.
So we should have two different mechanisms to modify the operation of the
GL? Welcome to the department of redundancy department!
> 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.
And when we have support for floating point texture formats (sooner than you
think!), the wrapper library will have to be updated AND will have to check
to see if the driver supports it. The doesn't sound much better than the
current situation of expecting apps to be updated. Admittedly, the wrapper
is one thing and we'll have the source, but still.
We have the same situation now with anisotropic filtering. Only the R100 &
R200 drivers support it now (I suppose the PowerVR & Nvidia drivers do too).
I can see how within Mesa or the driver we could easily default the initial
value of GL_TEXTURE_MAX_ANISOTROPY_EXT to some value other than 1. How
would you do the same in a wrapper library? You'd have to hook
glBindTexture and call glTexParameterf on the texture after the first (and
ONLY after the first) time the texture was bound to a given target. That
starts to sound like it would duplicate a lot of code that is already in
libGL AND like it would add an unnecessary performance penalty.
> 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*.
If you get down to it, it is for removing limits on GL settings that can be
set with a given app. For the most part this means trivial quality settings
like texel size and filtering. Why limit ourselves to that when quite a bit
more can be had very easilly?
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
-------------------------------------------------------
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
