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 Tue, 3 Dec 2002, Ian Romanick wrote:
Unless there are any objections, I'm going to commit a merge from the trunk
to the texmem-0-0-1 branch tomorrow (Wednesday). I've tested the merge on
the R100, and I'll test it on an M6 and a G400 before I commit it.
That's fine by me. FYI, I've
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
On Wed, Dec 04, 2002 at 02:35:39PM -0500, Leif Delgass wrote:
On Tue, 3 Dec 2002, Ian Romanick wrote:
Unless there are any objections, I'm going to commit a merge from the trunk
to the texmem-0-0-1 branch tomorrow (Wednesday). I've tested the merge on
the R100, and I'll test it on an M6
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, Dec 04, 2002 at 01:23:26 -0800, Ian Romanick wrote:
On Wed, Dec 04, 2002 at 02:35:39PM -0500, Leif Delgass wrote:
On Tue, 3 Dec 2002, Ian Romanick wrote:
Unless there are any objections, I'm going to commit a merge from the trunk
to the texmem-0-0-1 branch tomorrow (Wednesday).
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 Tue, Dec 03, 2002 at 05:05:26PM -0800, Ian Romanick wrote:
Unless there are any objections, I'm going to commit a merge from the trunk
to the texmem-0-0-1 branch tomorrow (Wednesday). I've tested the merge on
the R100, and I'll test it on an M6 and a G400 before I commit it.
I am in the
On Wed, Dec 04, 2002 at 02:30:03PM -0800, Ian Romanick wrote:
On Tue, Dec 03, 2002 at 05:05:26PM -0800, Ian Romanick wrote:
Unless there are any objections, I'm going to commit a merge from the trunk
to the texmem-0-0-1 branch tomorrow (Wednesday). I've tested the merge on
the R100, and
Might it not be possible to eliminate all the PCIGART_ENABLED stuff and for
the time being control this in the XF86Config. If you have a PCI card you
use ForcePCIMode true. If you have a AGP card you use either ForcePCIMode
false or just say nothing and the driver assumes AGP. This way the
I suspect that will fix the texture problems. Somebody (that actually has
Rage128 hardware!) should go through and eliminate the new_state field from
r128_context altogether. I will make similar changes to the MGA driver. It
would be nice to have fundamental things, like tracking state
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, 4 Dec 2002, Ian Romanick wrote:
On Wed, Dec 04, 2002 at 02:30:03PM -0800, Ian Romanick wrote:
On Tue, Dec 03, 2002 at 05:05:26PM -0800, Ian Romanick wrote:
Unless there are any objections, I'm going to commit a merge from the trunk
to the texmem-0-0-1 branch tomorrow (Wednesday).
Another note: A third-party tweak library could conceivably convert calls
for S3TC functionality into appropriate calls for ARB_texture_compression
instead.
--
http://trikuare.cx
---
This SF.net email is sponsored by: Microsoft Visual
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
30 matches
Mail list logo
