On Thu, Dec 05, 2002 at 12:58:49PM -0800, magenta wrote:
> 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:
> > > > ...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.
Well that sucks. I guess I'd never be able to enable super-sampled FSAA
with your wrapper on my R100. Even though I CAN do it with a driver-based
tweak utility on some other operating system.
> > > > 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?
Disabling TCL was the only example I could come up with in the existing
drivers. There are other valid examples in my thread with Allen on
selecting different driver fast-paths.
> > 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).
How does the config utility for the wrapper communicate with the user what
is available to tweak?
> > 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?
Because that behavior is wrong. It would over-ride settings that the app
would make. It's fine to change the default aniotropy from 1.0 to 8.0, but
if the app specifies 4.0, that setting had better be respected.
--
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
