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
Now you can have 100's of lenders compete for your loan!
Refinancing
New Home Loans
Debt Consolidation
Debt Consultation
Auto Loans
Credit Cards
Student Loans
Second Mortgage
Home Equity
Dear Homeowner,
Interest Rates are at their lowest point in 40 years!
We help you find the best rate
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] Wrapper library stuff (was: Re: Smoother graphics with 16bpp on radeon)
> From: magenta [mailto:[EMAIL PROTECTED]]
>
> Another note: A third-party tweak library could conceivably
> convert calls for S3TC functionality into appropriate calls for
> ARB_texture_compressi
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 applicatio
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
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
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
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 Studio.N
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 (Wed
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
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 changes
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,
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 PC
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 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: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 (W
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 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
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 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 sta
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 Mit, 2002-12-04 at 15:27, José Fonseca wrote:
> On Wed, Dec 04, 2002 at 02:48:50PM +0100, Michel Dänzer wrote:
> > On Mit, 2002-12-04 at 12:52, Keith Whitwell wrote:
> > > José Fonseca wrote:
> > > > Is there any reason no to enable x86 PCI support on Radeon?
> > >
> > > I think nobody's been
On Wed, Dec 04, 2002 at 03:41:06PM +0100, Alexander Stohr wrote:
> > One could pretend the Radeon driver isn't stable anyway so
> > people adding PCI support would not change that ;-))
>
> Can you consider code that is not publicly availabel as OpenSource?
>
> I mean if that code is not integr
Title: RE: [Dri-devel] Radeon x86 PCI [Was: help selecting a graphics
> > I don't think PCI cards work less stably than AGP cards per
> se, [...]
>
> One could pretend the Radeon driver isn't stable anyway so
> people adding PCI
> support would not change that ;-))
Can you consider code
On Wed, Dec 04, 2002 at 02:48:50PM +0100, Michel Dänzer wrote:
> On Mit, 2002-12-04 at 12:52, Keith Whitwell wrote:
> > José Fonseca wrote:
> > > Is there any reason no to enable x86 PCI support on Radeon?
> >
> > I think nobody's been able to make it work stably.
>
> I don't think PCI cards wor
> I don't think PCI cards work less stably than AGP cards per se, [...]
One could pretend the Radeon driver isn't stable anyway so people adding PCI
support would not change that ;-))
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
On Mit, 2002-12-04 at 12:52, Keith Whitwell wrote:
> José Fonseca wrote:
> > Is there any reason no to enable x86 PCI support on Radeon?
>
> I think nobody's been able to make it work stably.
I don't think PCI cards work less stably than AGP cards per se, the main
concern is AGP cards falling ba
José Fonseca wrote:
Is there any reason no to enable x86 PCI support on Radeon?
I think nobody's been able to make it work stably.
Keith
---
This SF.net email is sponsored by: Microsoft Visual Studio.NET
comprehensive development tool, bui
Is there any reason no to enable x86 PCI support on Radeon?
José Fonseca
- Forwarded message from Keith Gross <[EMAIL PROTECTED]> -
Date: Sun, 1 Dec 2002 19:19:24 +
From: Keith Gross <[EMAIL PROTECTED]>
Subject: Re: [Dri-users] help selecting a graphics card, and some general questi
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
43 matches
Mail list logo
