On Thu, Dec 05, 2002 at 11:48:10AM -0800, Ian Romanick wrote:
> 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.
Then I think we may be talking cross purposes.
> > > > 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.
Yes, I did reread it, which is why I then suggested glXChooseVisual as the
point of change (since it's in visual selection that it's enabled), which
is exactly the reason why it SHOULDN'T be in the driver - a wrapper library
could enable GL_ARB_multisample for the ATI and nVidia vendor drivers, even
though it couldn't do it for DRI at present. And if it doesn't work, then
the user turns that tweak off.
> > > 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!
No, because there's a very large difference between "disabling TCL for
debugging purposes" and "enabling 32bpp textures for quality purposes."
Why would a user want to disable TCL for anything other than debugging
the driver?
> > 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.
Yes, exactly - it's ONE THING that would have to be updated, and it would
apply to ALL DRIVERS.
> 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).
Yes, and so the tweak wrapper library would just fail to turn on
anisotropic filtering for drivers which don't support it. If the driver
doesn't support it, it's harmless, because the tweak will simply have no
effect, assuming the user even turns it on to begin with (and it's not like
the tweak library would ALWAYS turn on ALL tweaks - the point to it is to
give the USER the ability to configure the tweaks which are enabled WITHOUT
IT MESSING UP THE DRIVER ITSELF).
> 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.
What's wrong with just calling the appropriate function on all
glTexImage2D() calls?
> > 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?
Like what? And how does putting it into the driver make it any easier?
Then you still have to go through all of the pain and suffering of coming
up with a decent configuration mechanism.
--
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
