On Thu, Dec 05, 2002 at 01:23:42PM -0800, Ian Romanick wrote:
> >
> > 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.
But it's not even supported in the DRI driver on the R100... It's not like
the wrapper can magically make functionality which isn't there to begin
with appear, but in order to do the tweak in teh driver itself, the driver
would have to support it anyway! Unless I'm totally missing something
about how FSAA is done in OpenGL, in which case I'd love for someone to
explain. All of the documents I've found ont he web indicate that
GL_ARB_multisample is the way you do it, even in Windows.
> > 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.
Okay, the only example I can find right now (sourceforge's mailinglist
archival doesn't have the best threading interface I've seen...) is about
the vertex formats used in the internal representation. Obviously the
wrapper library couldn't configure that, but I don't understand why this
needs to be configured in the driver to begin with - if the driver supports
all the different vertex array formats internally, why doesn't it just
select which "conversion" (or fast path, or whatever) to perform based on
the data which is presented to it by the application to begin with?
Like, I thought that was the point to OpenGL's design in general - that the
driver would use the high-level information that's present in order to tune
its low-level operation, completely transparently to the user and
application.
> > > 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?
The way I envisioned it would be that the wrapper library would have a
configuration tool which would write the tweak profile out to a file, and
in the wrapper library's _init() it would read that profile in. The
location of the file would probably be specified in an environment
variable, and the launcher script would look something like this (only with
more sanity checking):
#!/bin/sh
TWEAKLIB=/path/to/libtweakGL.so
CONFDIR=${HOME}/.tweakGL/
APP=`basename "$1"`
if [ -f ${CONFDIR}/${APP} ] ; then
TGL_CONF=${CONFDIR}/${APP}
else
TGL_CONF=${CONFDIR}/default
fi
export TGL_CONF
LD_PRELOAD=${TWEAKLIB} "$@"
> > 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.
Good point.
Still, I think that for pretty much all applications, it'd be a pretty
simple matter to do something like this:
int newBind;
void glBindTexture(GLint handle)
{
newBind = 1;
real_glBindTexture(handle);
}
void glTexParameter{if}[v](GLenum target, GLenum param, {whatever} val)
{
if (newBind)
{
newBind = 0;
TweakTexture();
}
real_glTexParameterf(target, param, val);
}
TweakTexture()
{
/* setup anisotropic, trilinear, etc. */
}
This way, the TweakTexture() function would only be called the first time a
parameter is modified after a texture object is bound, and before the
application does its own parameter modification. Chances are the
application will only do glTexParameter when it's first setting up the
texture, and if it does do glTexParameter later on (in order to change its
own mipmap settings, etc.) hopefully it'll do whatever anisotropic
configuration it would do on its own then. :)
And, of course, for applications which already do anisotropic filtering,
the tweak library would hopefully have the anisotropic tweak turned off to
begin with.
--
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
