On Fri, Dec 06, 2002 at 09:26:49AM -0800, Ian Romanick wrote:
> On Thu, Dec 05, 2002 at 04:40:00PM -0800, magenta wrote:
> > On Thu, Dec 05, 2002 at 03:56:09PM -0800, Ian Romanick wrote:
> > >
> > > It is one way. It's the way that the OpenGL ARB has sanctified with an
> > > extension. It's not
On Thu, Dec 05, 2002 at 04:40:00PM -0800, magenta wrote:
> On Thu, Dec 05, 2002 at 03:56:09PM -0800, Ian Romanick wrote:
> > >
> > > 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
Apologies for re-ordering your comments, but I thought it might make my
reply more clear.
On Thu, Dec 05, 2002 at 05:38:41PM -0800, Linus Torvalds wrote:
|
| On Thu, 5 Dec 2002, Allen Akin wrote:
| >
| > Putting it in "kernel guy" terms, it's like sideband mechanisms for
| > talking to device-dep
On Thu, Dec 05, 2002 at 05:38:41PM -0800, Linus Torvalds wrote:
>
>
>
> On Thu, 5 Dec 2002, Allen Akin wrote:
> >
> > Putting it in "kernel guy" terms, it's like sideband mechanisms for
> > talking to device-dependent code in the kernel that bypass the syscall
> > interface. A few such things e
On Thu, 5 Dec 2002, Allen Akin wrote:
>
> Putting it in "kernel guy" terms, it's like sideband mechanisms for
> talking to device-dependent code in the kernel that bypass the syscall
> interface. A few such things exist for special purposes, but do you
> advocate using them as the normal way to
On Thu, Dec 05, 2002 at 04:57:06PM -0800, Linus Torvalds wrote:
>
> > I doubt the second one. Apparently my understanding of how FSAA is enabled
> > in an OpenGL application is flawed
>
> Yes. For one, you seem to think thatit's just a matterof selecting how
> many pixels to sample. That's not t
On Thu, 5 Dec 2002, magenta wrote:
> >
> > - FSAA _cannot_ be done by a wrapper. End of discussion. It needs driver
> >explicit support for it. It's not a "select one default value when
> >presented a choice" kind of passthrough thing.
>
> Why not?
Have you seen what the different FSAA c
On Thu, Dec 05, 2002 at 03:56:09PM -0800, Ian Romanick wrote:
> >
> > 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 driv
On Thu, Dec 05, 2002 at 03:28:49PM -0800, Linus Torvalds wrote:
| Let's put out some facts, instead of just arguing:
|
| - FSAA is a good idea...
Definitely.
| - FSAA _cannot_ be done by a wrapper. End of discussion.
Well, that depends on the hardware. Supersampled FSAA can be done
without d
On Thu, Dec 05, 2002 at 03:28:49PM -0800, Linus Torvalds wrote:
>
> On Thu, 5 Dec 2002, magenta wrote:
> > >
> > > 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 o
On Thu, Dec 05, 2002 at 02:13:26PM -0800, magenta wrote:
> 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 e
On Thu, 5 Dec 2002, magenta wrote:
> >
> > 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
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 lib
On Wed, Dec 04, 2002 at 06:28:55PM -0800, Allen Akin wrote:
> On Wed, Dec 04, 2002 at 02:21:30PM -0800, Ian Romanick wrote:
> | Remote indirect rendering is a problem no matter how you slice it.
>
> Well, maybe not if you handle preference-setting at the application
> level, rather than trying to
On Thu, Dec 05, 2002 at 03:21:46PM -0600, D. Hageman wrote:
> Careful, let us stick to the technical discussion rather then personal
> attacks on how I choose to express myself. Don't attack the analogies
> themselves, but rather the content that preceeded them and the point
> that they were ve
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
On Thu, 5 Dec 2002, magenta wrote:
>
> You just love those bad analogies. Do the people losing their ass in the
> stock market try to use a VW Bug as a boat?
>
Careful, let us stick to the technical discussion rather then personal
attacks on how I choose to express myself. Don't attack the ana
On Thu, Dec 05, 2002 at 02:15:10PM -0600, D. Hageman wrote:
> 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 t
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
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
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 s
On Thu, Dec 05, 2002 at 10:22:39AM -0800, Ian Romanick wrote:
> On Wed, Dec 04, 2002 at 03:52:39PM -0800, magenta wrote:
> > On Wed, Dec 04, 2002 at 02:21:30PM -0800, Ian Romanick wrote:
> > >
> > > As far as I can tell, there is no way either an app or a wrapper library
> > > could communicate th
Allen Akin wrote:
On Thu, Dec 05, 2002 at 11:43:51AM +, Keith Whitwell wrote:
|
| It's also a good description of how the Chromium configuration tools work...
Yep. If I understand correctly, though, the Chromium configuration
tools are intended mostly to allow SPUs and drivers and other low
On Wed, Dec 04, 2002 at 03:52:39PM -0800, magenta wrote:
> On Wed, Dec 04, 2002 at 02:21:30PM -0800, Ian Romanick wrote:
> >
> > As far as I can tell, there is no way either an app or a wrapper library
> > could communicate this information to the driver. Yet, shipping "high end"
> > drivers supp
On Thu, Dec 05, 2002 at 11:43:51AM +, Keith Whitwell wrote:
|
| It's also a good description of how the Chromium configuration tools work...
Yep. If I understand correctly, though, the Chromium configuration
tools are intended mostly to allow SPUs and drivers and other low-level
components t
Allen Akin wrote:
On Wed, Dec 04, 2002 at 01:39:19PM -0800, Ian Romanick wrote:
|
| Now, imagine the drivers having an interface that a tool (for creating app.
| profiles) could query. The driver would send back (perhaps using XML or
| something similar?) a list of "knobs" that is has in the for
On Thu, 5 Dec 2002 05:19:40 +0100
Alexander Stohr <[EMAIL PROTECTED]> wrote:
>
> > > What about remote indirect rendering? Someone else has
> > already mentioned
> > > that the driver would have no way of getting environment
> > variables in that
> > > case.
> >
> > Remote indirect rendering
On Thu, Dec 05, 2002 at 05:29:18AM +0100, Alexander Stohr wrote:
> The layer idea is not bad,
> but its more the taste of a hack.
> Remember that dri is OpenSource,
> so you dont need those hacks.
Just because something *can* be put into the source doesn't mean it
*should*. Have you ever heard th
magenta wrote:
See, the wrapper wouldn't have to communicate directly to the driver in
order to do any of what's been discussed - it would override it *based on
user preferences* using the existing high-level functionality provided by
OpenGL itself.
I agree. Building upon the OpenGL API itsel
Title: RE: [Dri-devel] Smoother graphics with 16bpp on radeon
The layer idea is not bad,
but its more the taste of a hack.
Remember that dri is OpenSource,
so you dont need those hacks.
As soon as you start with that you will notice that a layer
will increase distance between your
Title: RE: [Dri-devel] Smoother graphics with 16bpp on radeon
> > What about remote indirect rendering? Someone else has
> already mentioned
> > that the driver would have no way of getting environment
> variables in that
> > case.
>
> Remote indirect render
Title: glTune Proposal (was RE: [Dri-devel] Smoother graphics with 16bpp on radeon)
I was reading almost 80% of the discussion
and want to give you a quite "bold" sheme
of how that all can be handled in terms of
a real world system:
You'd write an extension to the drivers
On Wed, Dec 04, 2002 at 01:39:19PM -0800, Ian Romanick wrote:
|
| Now, imagine the drivers having an interface that a tool (for creating app.
| profiles) could query. The driver would send back (perhaps using XML or
| something similar?) a list of "knobs" that is has in the form:
|
| - Short nam
On Wed, Dec 04, 2002 at 02:21:30PM -0800, Ian Romanick wrote:
| Remote indirect rendering is a problem no matter how you slice it.
Well, maybe not if you handle preference-setting at the application
level, rather than trying to do it at the library or driver levels.
Then it can be dynamic, or ther
On Wed, Dec 04, 2002 at 02:21:30PM -0800, Ian Romanick wrote:
>
> As far as I can tell, there is no way either an app or a wrapper library
> could communicate this information to the driver. Yet, shipping "high end"
> drivers support and demanding users expect this level of
> application-to-drive
On Wed, Dec 04, 2002 at 01:49:34PM -0800, magenta wrote:
> What about remote indirect rendering? Someone else has already mentioned
> that the driver would have no way of getting environment variables in that
> case.
Remote indirect rendering is a problem no matter how you slice it.
> I just do
On Wed, Dec 04, 2002 at 02:33:11PM -0700, Jens Owen wrote:
> magenta wrote:
> >
> > 3. Users should not be able to configure default behavior; applications
> > should specify all behavior explicitly if it matters, and expose this as an
> > application-level configuration option to the user
> >
>
On Wed, Dec 04, 2002 at 01:57:48PM -0700, Nicholas Leippe wrote:
> On Wednesday 04 December 2002 01:06 pm, you wrote:
> >
> > I basically see three camps in this discussion:
> >
> > 1. Users should be able to configure default behavior using configuration
> > files (which would be selected based
On Wed, Dec 04, 2002 at 01:57:48PM -0700, Nicholas Leippe wrote:
> It seems as if none of the levels of controls people have been asking for in
> this thread can't be satisfied via environment variables in one way or
> another--it seems to be the most flexible solution.
The problem with env vars
Am Mittwoch, 4. Dezember 2002 21:18 schrieb Ian Romanick:
> On Wed, Dec 04, 2002 at 12:06:20PM -0800, magenta wrote:
> > On Wed, Dec 04, 2002 at 11:06:01AM -0800, Allen Akin wrote:
> > > On Wed, Dec 04, 2002 at 12:57:44AM -0600, D. Hageman wrote:
> > > | This illustrates one of the bad points of us
magenta wrote:
I basically see three camps in this discussion:
1. Users should be able to configure default behavior using configuration
files (which would be selected based on argv[0] or similar)
2. Users should be able to configure default behavior using environment
variables (which would be
On Wednesday 04 December 2002 01:06 pm, you wrote:
>
> I basically see three camps in this discussion:
>
> 1. Users should be able to configure default behavior using configuration
> files (which would be selected based on argv[0] or similar)
>
> 2. Users should be able to configure default beha
On Wed, 4 Dec 2002, magenta wrote:
> On Wed, Dec 04, 2002 at 02:30:31PM -0600, D. Hageman wrote:
> > On Wed, 4 Dec 2002, magenta wrote:
> > >
> > > Actually, I just thought of a solution which could possibly satisfy all
> > > three camps: have a libGL wrapper library (loaded via LD_PRELOAD) which
On Wed, Dec 04, 2002 at 12:18:03PM -0800, Ian Romanick wrote:
> > 1. Users should be able to configure default behavior using configuration
> > files (which would be selected based on argv[0] or similar)
> >
> > 2. Users should be able to configure default behavior using environment
> > variables
On Wed, Dec 04, 2002 at 02:30:31PM -0600, D. Hageman wrote:
> On Wed, 4 Dec 2002, magenta wrote:
> >
> > Actually, I just thought of a solution which could possibly satisfy all
> > three camps: have a libGL wrapper library (loaded via LD_PRELOAD) which
> > overrides functionality as needed. Want
On Wed, 4 Dec 2002, magenta wrote:
>
> Actually, I just thought of a solution which could possibly satisfy all
> three camps: have a libGL wrapper library (loaded via LD_PRELOAD) which
> overrides functionality as needed. Want to force FSAA to be enabled? Put
> it into glXCreateContext(). Want
On Wed, Dec 04, 2002 at 12:06:20PM -0800, magenta wrote:
> On Wed, Dec 04, 2002 at 11:06:01AM -0800, Allen Akin wrote:
> > On Wed, Dec 04, 2002 at 12:57:44AM -0600, D. Hageman wrote:
> > | This illustrates one of the bad points of using environment variables.
> > | Will we have to add environment
On Wed, Dec 04, 2002 at 11:06:01AM -0800, Allen Akin wrote:
> On Wed, Dec 04, 2002 at 12:57:44AM -0600, D. Hageman wrote:
> | This illustrates one of the bad points of using environment variables.
> | Will we have to add environment variables every time a new app is pushed
> | out the door? Bad
On Wed, Dec 04, 2002 at 12:57:44AM -0600, D. Hageman wrote:
| This illustrates one of the bad points of using environment variables.
| Will we have to add environment variables every time a new app is pushed
| out the door? Bad approach.
In general, if a bug affects every app, then the drive
On Wed, Dec 04, 2002 at 11:12:46AM +0100, Felix Kühling wrote:
| One thing we should keep in mind about the future is indirect rendering.
| Environment variables which are only known on the client side won't work
| then. ...
Good point.
Allen
On Tue, 3 Dec 2002 11:29:34 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Tue, 3 Dec 2002, magenta wrote:
> >
> > User preferences are an entirely different matter. I totally agree that
> > the user should be able to override default behaviors, but environment
> > variables are s
On Tue, 3 Dec 2002, Allen Akin wrote:
>
> No, and as I've said several times before, I don't have a major problem
> with it as long as the "knob" that controls the workaround is
> application-specific. For example, if the workaround is for Q3A and
> we're using environment variables, then the var
On Tue, Dec 03, 2002 at 05:02:36PM -0800, Ian Romanick wrote:
|
| ...It's the year 2002 (almost 2003) and I can actually
| choose how to operate my computer instead of having somebody else dictate it
| to me...
Let me get this straight. The lack of ability to add new features to
On Tue, Dec 03, 2002 at 04:35:49PM -0800, Linus Torvalds wrote:
|
| > Depends. How much performance will I lose on my machine when I force
| > anisotropic filtering on? Just because you can turn the feature on
| > doesn't mean you automatically get a "better user experience."
|
| But that's the
On Tue, Dec 03, 2002 at 04:15:40PM -0800, Allen Akin wrote:
> On Tue, Dec 03, 2002 at 03:29:32PM -0800, Ian Romanick wrote:
> |
> | ... On Windows, I can go into the OpenGL tuning app for my driver and
> | click 'force anisotropic filtering.' Since this extension was created AFTER
> | Quake,
On Tue, 3 Dec 2002, Allen Akin wrote:
>
> Depends. How much performance will I lose on my machine when I force
> anisotropic filtering on? Just because you can turn the feature on
> doesn't mean you automatically get a "better user experience."
But that's the POINT!
This is not a decision tha
On Tue, Dec 03, 2002 at 03:29:32PM -0800, Ian Romanick wrote:
|
| ... On Windows, I can go into the OpenGL tuning app for my driver and
| click 'force anisotropic filtering.' Since this extension was created AFTER
| Quake, there's NO WAY to enable it from Quake. In Linux I get tough
| cooki
On Tue, Dec 03, 2002 at 03:18:26PM -0800, Allen Akin wrote:
> On Tue, Dec 03, 2002 at 03:42:06PM -0700, Nicholas Leippe wrote:
> | I guarantee you that the only thing truly knowledgeable enough to make such
> | tradeoffs is the user at the keyboard, not the programmer writing the
> | application
On Tue, Dec 03, 2002 at 03:42:06PM -0700, Nicholas Leippe wrote:
| I guarantee you that the only thing truly knowledgeable enough to make such
| tradeoffs is the user at the keyboard, not the programmer writing the
| application somewhere else on different hardware with different tastes.
Maybe I
On Tuesday 03 December 2002 12:35 pm, you wrote:
> On Tue, Dec 03, 2002 at 10:14:45AM -0800, Linus Torvalds wrote:
> |
> | Why? I don't understand this reluctance to just admit that the _user_ may
> | be right.
>
> I note your use of the word "may." Sometimes the user can happily
> express a si
Am Dienstag, 3. Dezember 2002 21:02 schrieb Ian Romanick:
> On Tue, Dec 03, 2002 at 11:29:34AM -0800, Linus Torvalds wrote:
> > On Tue, 3 Dec 2002, magenta wrote:
> > > User preferences are an entirely different matter. I totally agree
> > > that the user should be able to override default behavio
On Tue, 2002-12-03 at 21:01, D. Hageman wrote:
> easy ... enough said on that. *If* a system is going to be more user
> friendly, then configuration files (text based) are the way to go. My
Not really
> options based on that. A GUI tool that could easily edit this file should
> be the ultim
I will have to balk on Linus' opinion in this situation. I will admit
that for a hacker, environment variables are the way to go. Quick and
easy ... enough said on that. *If* a system is going to be more user
friendly, then configuration files (text based) are the way to go. My
reasoning f
On Tue, Dec 03, 2002 at 11:29:34AM -0800, Linus Torvalds wrote:
> ... They are also often much more efficient and
> easier to use than config files (ie "just say no to another config file
> parser").
Another note: The amount of code needed to parse a configuration file isn't
signifigantly more tha
On Tue, Dec 03, 2002 at 11:29:34AM -0800, Linus Torvalds wrote:
>
> On Tue, 3 Dec 2002, magenta wrote:
> >
> > User preferences are an entirely different matter. I totally agree that
> > the user should be able to override default behaviors, but environment
> > variables are such a crappy way of
On Tue, Dec 03, 2002 at 11:29:34AM -0800, Linus Torvalds wrote:
>
> On Tue, 3 Dec 2002, magenta wrote:
> >
> > User preferences are an entirely different matter. I totally agree that
> > the user should be able to override default behaviors, but environment
> > variables are such a crappy way of
On Tue, Dec 03, 2002 at 12:24:22PM +0100, Felix Kühling wrote:
| ...
| But the choice for the following internalformats also depends on the
| screen color depth in the current implementation:
|
|case GL_RGBA8:
|case GL_RGB10_A2:
|case GL_RGBA12:
|case GL_RGBA16:
|
|case GL_RGB
On Tue, Dec 03, 2002 at 11:22:00AM -0800, Linus Torvalds wrote:
| ... You should look at what Windows drivers do. And they
| _all_ have user-settable preferences for things like texture quality etc.
We should look at where Windows drivers are going, not where they are
today.
There
On Tue, Dec 03, 2002 at 10:14:45AM -0800, Linus Torvalds wrote:
|
| Why? I don't understand this reluctance to just admit that the _user_ may
| be right.
I note your use of the word "may." Sometimes the user can happily
express a simple preference, but often such a choice has consequences
that
On Tue, 3 Dec 2002, magenta wrote:
>
> User preferences are an entirely different matter. I totally agree that
> the user should be able to override default behaviors, but environment
> variables are such a crappy way of doing this.
Why? Environment variables are in many ways more powerful than
On Tue, 3 Dec 2002, Brian Paul wrote:
>
> It's also my experience with many implementations of OpenGL that drivers
> lean toward quality in this scenario.
I think that's true, but I think that's partly because of the fact that
most OpenGL implementations are geared toward things like CAD design
Am Dienstag, 3. Dezember 2002 19:32 schrieb Linus Torvalds:
> On Tue, 3 Dec 2002, magenta wrote:
> > > Ugh. The internalFormat is itself a hint. If the programmer cares
> > > about how much storage is used or the quality, he/she should use
> > > GL_RGB4, GL_RGB8, GL_RGB16, etc.
> >
> > Oh yeah.
On Tue, Dec 03, 2002 at 10:32:50AM -0800, Linus Torvalds wrote:
>
> On Tue, 3 Dec 2002, magenta wrote:
> > >
> > > Ugh. The internalFormat is itself a hint. If the programmer cares about
> > > how much storage is used or the quality, he/she should use GL_RGB4, GL_RGB8,
> > > GL_RGB16, etc.
> >
Ian Romanick wrote:
On Tue, Dec 03, 2002 at 07:31:11AM -0700, Brian Paul wrote:
Felix Kühling wrote:
On Mon, 2 Dec 2002 18:43:25 -0800
Allen Akin <[EMAIL PROTECTED]> wrote:
On Mon, Dec 02, 2002 at 02:00:49PM +0100, Felix Kühling wrote:
| So if we agree on this, I
On Tue, 3 Dec 2002, magenta wrote:
> >
> > Ugh. The internalFormat is itself a hint. If the programmer cares about
> > how much storage is used or the quality, he/she should use GL_RGB4, GL_RGB8,
> > GL_RGB16, etc.
>
> Oh yeah. Heh.
Oh, NO! No "Heh".
The whole argument about "if the program
Linus Torvalds wrote:
On Tue, 3 Dec 2002, Brian Paul wrote:
Otherwise, by using a generic format like GL_RGB the user is indicating
that he doesn't especially care. In this case, I think the driver should
lean toward the higher quality texture formats.
Why? I don't understand this reluctance
On Tue, 3 Dec 2002, Brian Paul wrote:
>
> Otherwise, by using a generic format like GL_RGB the user is indicating
> that he doesn't especially care. In this case, I think the driver should
> lean toward the higher quality texture formats.
Why? I don't understand this reluctance to just admit th
On Tue, Dec 03, 2002 at 10:31:41AM -0700, Brian Paul wrote:
> magenta wrote:
> > On Tue, Dec 03, 2002 at 02:38:15PM +, Keith Whitwell wrote:
> >
> >>>I'm with Allen in preferring that we don't add yet another environment
> >>>variable - especially for something which other OpenGL drivers haven
On Tue, Dec 03, 2002 at 11:31:41AM -0600, D. Hageman wrote:
> On Tue, 3 Dec 2002, magenta wrote:
>
> > On Tue, Dec 03, 2002 at 02:38:15PM +, Keith Whitwell wrote:
> > > > I'm with Allen in preferring that we don't add yet another environment
> > > > variable - especially for something which ot
On Tue, 3 Dec 2002, Leif Delgass wrote:
> On Tue, 3 Dec 2002, Brian Paul wrote:
>
> > > There was previously a dependency on the screen color depth when
> > > choosing the texture format in the radeon driver.
> >
> > I think that may have been a carry-over from the r128 (or tdfx?) driver
> > whi
On Tue, 3 Dec 2002, magenta wrote:
> On Tue, Dec 03, 2002 at 02:38:15PM +, Keith Whitwell wrote:
> > > I'm with Allen in preferring that we don't add yet another environment
> > > variable - especially for something which other OpenGL drivers haven't
> > > needed.
> >
> > Hmm. Windows driver
On Tue, 3 Dec 2002, Keith Whitwell wrote:
>
> > I'm not sure that statement is accurate. On SGI, AIX, and Windows there are
> > various tools to tune the operation of the OpenGL driver. On Linux we don't
> > have any of that. Instead we've been using an ad-hoc collection of
> > environment var
On Tue, 3 Dec 2002, Brian Paul wrote:
> > There was previously a dependency on the screen color depth when
> > choosing the texture format in the radeon driver.
>
> I think that may have been a carry-over from the r128 (or tdfx?) driver
> which may not have allowed 32bpp textures when the screen
magenta wrote:
On Tue, Dec 03, 2002 at 02:38:15PM +, Keith Whitwell wrote:
I'm with Allen in preferring that we don't add yet another environment
variable - especially for something which other OpenGL drivers haven't
needed.
Hmm. Windows drivers tend to have a GUI setup utility, which oft
On Tue, Dec 03, 2002 at 02:38:15PM +, Keith Whitwell wrote:
> > I'm with Allen in preferring that we don't add yet another environment
> > variable - especially for something which other OpenGL drivers haven't
> > needed.
>
> Hmm. Windows drivers tend to have a GUI setup utility, which often
I'm not sure that statement is accurate. On SGI, AIX, and Windows there are
various tools to tune the operation of the OpenGL driver. On Linux we don't
have any of that. Instead we've been using an ad-hoc collection of
environment variables to control debug output, HW TCL operation, page
flipp
On Tue, Dec 03, 2002 at 07:31:11AM -0700, Brian Paul wrote:
> Felix Kühling wrote:
> > On Mon, 2 Dec 2002 18:43:25 -0800
> > Allen Akin <[EMAIL PROTECTED]> wrote:
> >
> >
> >>On Mon, Dec 02, 2002 at 02:00:49PM +0100, Felix Kühling wrote:
> >>| So if we agree on this, I w
Brian Paul wrote:
Felix Kühling wrote:
On Mon, 2 Dec 2002 18:43:25 -0800
Allen Akin <[EMAIL PROTECTED]> wrote:
On Mon, Dec 02, 2002 at 02:00:49PM +0100, Felix Kühling wrote:
| So if we agree on this, I would make this
| controlled by an environment variable. ...
The
Felix Kühling wrote:
On Mon, 2 Dec 2002 18:43:25 -0800
Allen Akin <[EMAIL PROTECTED]> wrote:
On Mon, Dec 02, 2002 at 02:00:49PM +0100, Felix Kühling wrote:
| So if we agree on this, I would make this
| controlled by an environment variable. ...
The intent of the spec
On Mon, 2 Dec 2002 18:43:25 -0800
Allen Akin <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 02, 2002 at 02:00:49PM +0100, Felix Kühling wrote:
> | So if we agree on this, I would make this
> | controlled by an environment variable. ...
>
> The intent of the spec is that driver
On Sun, Dec 01, 2002 at 02:12:08PM -0500, Leif Delgass wrote:
| According to section 4.1.8 of the OpenGL 1.4 spec: "Initially, dithering
| is enabled" -- so that should always be the initial default.
Right.
Glean disables dithering in some cases (particularly when object identifiers
are encoded
On Mon, Dec 02, 2002 at 02:00:49PM +0100, Felix Kühling wrote:
| So if we agree on this, I would make this
| controlled by an environment variable. ...
The intent of the spec is that drivers should support whichever texture
internal formats they wish to support, and apps
On Mon, 02 Dec 2002 10:47:54 +
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote:
> > Hi,
> >
> > I made two small modifications to the radeon driver to make OpenGL look
> > much nicer with 16bpp. The first thing is to enable dithering, the
> > second is to use 32bpp textures ev
Felix Kühling wrote:
Hi,
I made two small modifications to the radeon driver to make OpenGL look
much nicer with 16bpp. The first thing is to enable dithering, the
second is to use 32bpp textures even in 16bpp mode, if the application
requests them. A patch is attached.
I've turned it on unilat
On Sun, 1 Dec 2002, Keith Whitwell wrote:
> Felix Kühling wrote:
> > Hi,
> >
> > I made two small modifications to the radeon driver to make OpenGL look
> > much nicer with 16bpp. The first thing is to enable dithering, the
> > second is to use 32bpp textures even in 16bpp mode, if the applicatio
On Sun, 1 Dec 2002 17:01:44 +0100
Felix Kühling <[EMAIL PROTECTED]> wrote:
[snip]
> I couldn't run a complete glean test. It failed with "Error: Could not
> get dma buffer... exiting". The strange thing is, this only happened if
> the glean standard output went to an rxvt in the background. When I
On Sun, 01 Dec 2002 14:57:45 +
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote:
[snip]
> > Index: radeon_state_init.c
> > ===
> > RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_state_init.c,v
> > re
Felix Kühling wrote:
Hi,
I made two small modifications to the radeon driver to make OpenGL look
much nicer with 16bpp. The first thing is to enable dithering, the
second is to use 32bpp textures even in 16bpp mode, if the application
requests them. A patch is attached.
Maybe the texture color d
98 matches
Mail list logo
