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 appear, but
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, 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
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 do
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
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 the
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 exactly the
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 other
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
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 driver
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 cards can
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 the
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 exist for
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 what the
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
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 very
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 such a
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
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: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 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 (which
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 behavior
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
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 using
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
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 to
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 argv[0]
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: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 don't
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-driver
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 to force
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 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
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 name
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 that
advertises all
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 rendering is a problem no matter how you slice
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
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 drivers
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
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
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 would make this
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
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 has
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
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 was
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 variables
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
which may not
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't
needed.
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 that
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
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 programmer cares
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, 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.
Oh yeah.
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. Heh.
Oh,
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, 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:
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
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.
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
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 doing
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 doing
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 than
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 behaviors, but
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 other OpenGL
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
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 simple
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
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, 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 ultimate
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
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
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 even in 16bpp
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 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
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 depth should be
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
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
retrieving
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, 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 application
79 matches
Mail list logo
