How about moving
os-support/{linux,bsd}/drm/kernel/drm.h
into
os-support/shared/drm/kernel/drm.h
After all, it defines the core drm IOCTLS and data structures. It should be
common, not in OS-specific directories.
There are trivial differences between the two versions right now, that
could eas
Keith Whitwell wrote:
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, l
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
Philip Brown wrote:
How about moving
os-support/{linux,bsd}/drm/kernel/drm.h
into
os-support/shared/drm/kernel/drm.h
After all, it defines the core drm IOCTLS and data structures. It should be
common, not in OS-specific directories.
There are trivial differences between the two versions righ
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 Wed, Dec 04, 2002 at 03:29:51 -0800, 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 b
hi,
dunno if this is the right place so god forgive me! i didnt get any help in
DRI-users or irc nor web.
i have problems getting direct rendering on X 4.2.99.2 with the
r200-20021130-linux.i386 binary snapshot.
this is what glxinfo says:
libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0)
> hi,
> dunno if this is the right place so god forgive me! i didnt get any help in
> DRI-users or irc nor web.
>
> i have problems getting direct rendering on X 4.2.99.2 with the
> r200-20021130-linux.i386 binary snapshot.
> this is what glxinfo says:
>
> libGL: XF86DRIGetClientDriverName: 4.0.1 r
I'll second Keith Gross here: we should enable PCI support even if there
are situations were it can cause problems, as the situations can be
avoided with proper configuration and more people could enjoy DRI.
After all, we strive to add functionality to the drivers, not to hide it
from users, and i
The commit of the merge is done. I checked-out the branch and compared it
with my repository, and everything looks good.
I do apologize for not properly tagging the branch before or after the
merge. I will remember to do that in the future.
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.
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 I'll test it on an M6 and a G400 before I commit
TRUE UNLIMITED LONG DISTANCE NO EXTRA COST 100% FLAT RATE ONLY $49.95 PER MONTH! Are you tired of the lies from AT&T and MCI about their so-called flat rate plans? Then when you get your phone bill you find out they did nothing more than to lure you in as a customer to charge you seven cents or mo
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
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
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 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
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
Hello,
I don't know if this information is of any use, but I thought I'd post it
anyway.
In purpose of producing some gdb-output I started an X server without any
further function - just by running 'X', no xdm query, nothing. I'm using an
X server and OpenGL libraries built from today's DRI CVS tr
> I exported DISPLAY to the local X server (:0.0) and following that I started
> 'fgfs' with several options - as usual. This time I added
> '--enable-fullscreen' (looks really nice then). Usually the screen locks up
> after 20 to 40 seconds - this time I flew several minutes - until I crashed
> th
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
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 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 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 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, Dec 05, 2002 at 08:16:57AM -0800, Ian Romanick wrote:
> The commit of the merge is done. I checked-out the branch and compared it
> with my repository, and everything looks good.
>
> I do apologize for not properly tagging the branch before or after the
> merge. I will remember to do tha
In fact, don't do a texmem-to-trunk just yet :)
I extremely funky textures with r128 now.
Alan.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
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 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: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, 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 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, 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 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, 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
Actually 1 and 2 are correct for unit 0 and 1, since they are bitflags.
However, this switch/case isn't needed at all here since the flags are
updated elsewhere. The default was hit with a value of zero because
t->base.bound isn't actually set until after this (in update_tex_common in
r128_texst
Title: Make Money at HOME
Make Money at HOME !
Make over
$900 a week
You can work at home now.
Earn over $900 a week from
HOME
A real home business
opportunity.
Find out more
Anti-SPAM
Policy Disclaimer: Under Bill s.1618 Title III passe
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 07:25:08PM -0800, Allen Akin wrote:
>
> But to make this constructive, I think the best thing we can do is to
> generate a list of the state that people want to tweak. There's a lot
> of low-level state, so it could be a *very* long list. Once it exists,
> we'll have a be
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, 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 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
42 matches
Mail list logo
