Alex Deucher wrote:
As I recall KDE preloads libGL for some reason. that might have
something to do with it.
If you make sure that the old driver.so file is removed, not overwritten,
there shouldn't be any problem, as existing open filehandles won't then see
any changes.
I'm not sure if the XFr
Felix Kühling wrote:
IIRC, the radeon driver still uses AGP writeback. This doesn't work
reliably on my system and I disabled it in my local tree. Some people
(including myself) have been thinking about an efficient algorithm to
detect unreliable writeback, but AFAICT nobody came up with anything y
Roland Scheidegger wrote:
Slightly OT, but here's an article comparing XiG Summit, dri cvs and the
ATI driver on a radeon 9000pro.
http://homepage.hispeed.ch/rscheidegger/atilinux_oct03/ati_linux_comp_oct03.html
And to get this fully on-topic, is there a specific reason why the dri
driver is qu
Ville Syrjälä wrote:
My previous comment on irc about anisotropic filtering needing two mip
levels was crap. Fortunately I've since managed to figure out the real
details.
The good news is that G550 doesn't have any problems with anisotropic
filtering.
The bad news is that G4x0 chips need both text
Alex Deucher wrote:
That's fine with me. we can revert back to xfree86 CVS for the trunk
and I can move to a branch. I wouldn't have put it on the trunk if I
had know the mode stuff was cause so much trouble, but then again, it's
been working fine for me and those who initially tested it, so I ne
Michel Dänzer wrote:
On Tue, 2003-10-14 at 21:58, Alex Deucher wrote:
The reason mergedfb is enabled by default is to emulate the clone
behavior in the old driver. perhaps this should be changed in the
future?
In the mean time, I may switch back to validating the modes on crtc2
before crtc1. th
Michel Dänzer wrote:
On Mon, 2003-10-13 at 12:50, Felix Kühling wrote:
On Sun, 12 Oct 2003 22:46:38 +0200
Michel Dänzer <[EMAIL PROTECTED]> wrote:
On Sun, 2003-10-12 at 00:15, Felix Kühling wrote:
On Sat, 11 Oct 2003 01:49:27 +0200
Michel Dänzer <[EMAIL PROTECTED]> wrote:
This means that most en
John Dennis wrote:
The locking problem is solved, my original analysis was incorrect. The
problem was that DRM_CAS was not correctly implemented on IA64. Thus
this was an IA64 issue only, this is consistent with others who showed
up in a google search describing the problem, all were on IA64.
I hav
Right. And certainly now with the new linear allocator the Xserver can
manage the whole lot.
Does the X server make any promises about preserving the contents of the fb
memory? EG, if there's a VT switch, will the contents be saved somehow?
No. No preservation is done. We need to invalidate ev
Alan Hourihane wrote:
On Thu, Oct 09, 2003 at 06:36:11PM +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
On Thu, Oct 09, 2003 at 05:30:08PM +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
I've just committed a version of the DRI's common code mm.[ch] linear
allocator
into t
Alan Hourihane wrote:
On Thu, Oct 09, 2003 at 05:30:08PM +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
I've just committed a version of the DRI's common code mm.[ch] linear
allocator
into the XFree86 CVS which extends the FBManager's ability to serve
real linear space rathe
Alan Hourihane wrote:
I've just committed a version of the DRI's common code mm.[ch] linear allocator
into the XFree86 CVS which extends the FBManager's ability to serve
real linear space rather than pinching it from the XY area's that's
usually occupied by the pixmap cache.
This way we can now han
Alan Hourihane wrote:
Anyone know why the nr_heaps was forced to 1 in r200_context.c ?
The agp memory that would have been the agp texture heap is being used instead
for glxAllocateMemoryNV.
Keith
---
This SF.net email is sponsored by: SF.net
Jacek Rosik wrote:
W liście z pon, 06-10-2003, godz. 15:28, Keith Whitwell pisze:
I know that vertex are accumulated and then are sent to the hardware.
Is it possible (hard?) to do something like this in order to render
into more than buffer.
radeonSetBuffer(GL_FRONT_LEFT
Felix Kühling wrote:
On Wed, 08 Oct 2003 10:38:04 +0100
Keith Whitwell <[EMAIL PROTECTED]> wrote:
Felix Kühling wrote:
Hi,
I have a working copy of the config-0-0-1-branch with the trunk merged
in now. According to the CVS policy I would have to commit this to the
branch. However, this wo
Felix Kühling wrote:
Hi,
I have a working copy of the config-0-0-1-branch with the trunk merged
in now. According to the CVS policy I would have to commit this to the
branch. However, this would be a huge commit due to the intermediate
merge from XFree86. cvs diff -uN outputs a 323074-lines patch
Otto Solares wrote:
Hi!
I am trying to merge the r200 driver from dri-cvs to mesa-miniglx,
finally i had most files merged but i am finding heavy X dependencies
in header files in dri-cvs (eg radeon.h), it was not supposed dri
drivers should be backend agnostic?
Is somebody working on resolving th
Eric Anholt wrote:
On Tue, 2003-10-07 at 10:42, Alex Deucher wrote:
I have a question about the license at the top of these new files.
what should I put for the copyright? Some of the the code was written
by me, but much of it was taken from the sis and mga drivers. Also,
what to I put for the
John Dennis wrote:
I've been trying to track down a DRI client and server deadlock
problem. I think I now know the problem, I'd appreciate it if others
could confirm this is a bug or if I have a misunderstanding.
This is the scenario:
1) Client takes heavyweight lock via ioctl, lock now has DRM_LO
José Fonseca wrote:
On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote:
Hi all,
I'm happy to report that I found a solution to the merge problems Eric
and I were seeing. I believe the problem had to do with vendor branches.
They are created automatically when sources are imported using
Jacek Rosik wrote:
W lis'cie z pon, 06-10-2003, godz. 10:38, Keith Whitwell pisze:
Ok I got it, but I have a question. In DRITransitionX functions in
dri.c DRIClipNotifyAllDrawables is called. I don't quite understand
purpose of this functions but I think it should also get ca
Jacek Rosik wrote:
W liście z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze:
BTW: As I'am working on stereo now I need to allocate additional
buffers for left eye buffers. Currently I allocate them whenever
TransitionTo3D is called, but I think it would be quite useful if I
would add Trans
Peter Lamberg wrote:
copyTexImage2D et al. seem horribly slow for anything more than few
hundred pixels.
It seems from radeon_tex.c that frame buffer -> texture operations are
implemented without any hardware help from the card:
ctx->Driver.CopyTexImage1D= _swrast_copy_teximage1d
Keith Whitwell wrote:
John Dennis wrote:
[Note: this is cross posted between dri-devel and [EMAIL PROTECTED] ]
I'm trying to debug a hung X server problem with DRI using the radeon
driver. Sources are XFree86 4.3.0. This happens to be on ia64, but at
the moment I don't see anything ar
John Dennis wrote:
[Note: this is cross posted between dri-devel and [EMAIL PROTECTED] ]
I'm trying to debug a hung X server problem with DRI using the radeon
driver. Sources are XFree86 4.3.0. This happens to be on ia64, but at
the moment I don't see anything architecture specific about the probl
Alan Hourihane wrote:
On Tue, Sep 30, 2003 at 07:35:46PM +0100, Alan Hourihane wrote:
On Tue, Sep 30, 2003 at 07:54:00PM +0200, Jacek Rosik wrote:
W liście z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze:
On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote:
W liście z wto, 30-09-2
Jacek Rosik wrote:
W liście z wto, 30-09-2003, godz. 19:29, Alan Hourihane pisze:
On Tue, Sep 30, 2003 at 07:21:14PM +0200, Jacek Rosik wrote:
W liście z wto, 30-09-2003, godz. 18:52, Alan Hourihane pisze:
In radeon_dri.c in the TransitionTo2d/3d there's some offscreen memory
allocation going
Michel Dänzer wrote:
On Tue, 2003-09-30 at 15:58, Alan Hourihane wrote:
Does anyone know why the radeon & r128 drivers call FLUSH_RING when in
the BlockHandler ?
This is the best way to ensure that the indirect buffer gets flushed
according to Mark Vojkovich. Without it, drawing operations could
Alan Hourihane wrote:
Does anyone know why the radeon & r128 drivers call FLUSH_RING when in
the BlockHandler ?
No -- seems unnecessary. Perhaps a hangover from the days when 2D accel was
disabled with dri?
Keith
---
This sf.net email is spo
José Fonseca wrote:
On Tue, Sep 30, 2003 at 11:16:54AM +0100, Keith Whitwell wrote:
José Fonseca wrote:
On Tue, Sep 30, 2003 at 12:24:53AM +0100, José Fonseca wrote:
PS: For general information, the HEAD failed to build somehere in the
SiS driver. And the s3virge seems to have the missing
Alan Hourihane wrote:
On Tue, Sep 30, 2003 at 11:02:13AM +0100, Alan Hourihane wrote:
Is it worth moving the remaining DRI drivers into Mesa for the 6.0 release ?
It seems as though mga, r128, r200 and radeon are already there.
Actually,
Do it this way we can fork the drivers for the Mesa 6.0
José Fonseca wrote:
On Tue, Sep 30, 2003 at 12:24:53AM +0100, José Fonseca wrote:
Anyway, I'm now building a snapshot. If it succeeds please do a public
request for testing on the dri-users and dri-devel.
Just to let you know that the config snapshots built without any incident.
Regards,
José
Alan Hourihane wrote:
On Tue, Sep 30, 2003 at 11:31:04AM +0200, Michel Dänzer wrote:
On Tue, 2003-09-30 at 11:13, Alan Hourihane wrote:
I looked at your original commit message and it didn't give any reason
why you did it in the first place.
I followed up to your commit, check out the dri-devel a
Daniel Borca wrote:
Hi!
I was just asking myself about the s and t factors in fxTexGetInfo. Why are they 256.0 limited? Is that enough for large textures?
Voodoo 1 and 2 where limited to a maximum of 256x256 texture size.
'k, I know that! But when using large textures, should those factors sca
Jacek Rosik wrote:
Hi!
I've been working on adding stereo support for radeon/r200 driver
recently. I have several questions mainly about kernel side and
interrupts.
1) About CP. As I understand it it's some kind of queue for commands.
So, is there such posibility that if I write some value into re
Markus Fakler wrote:
Hello!
I'm developing a graphic driver for radeon cards
as part of a research OS ("PLURIX") at an university.
We're already supporting the R100-based radeon cards
(including the (simple) TCL) and want also to support
the R200-based cards.
But with these cards I have a big prob
José Fonseca wrote:
I've finished with a big chunk of the wikification of the website,
including updating CVS download info.
These would be the new top leves entry pages:
Home: http://dri.sf.net/cgi-bin/moin.cgi/FrontPage
Status: http://dri.sf.net/cgi-bin/moin.cgi/Status
Contribute: http://
Dave Airlie wrote:
if one of our SF admins, goes project admin->CVS and unticks the box, it
will disappear from the project page, but the CVS repo will not be
touched.. or at least thats wehat it says..
Done...
Keith
---
This sf.net email is s
Has the website been updated to point users/new developers to the new
freedesktop.org address for anonymous CVS?
I don't know if there is anything we can do about the sf.net project pages to
stop them erroneously referring people to the sf.net cvs?
Keith
-
Keith Whitwell wrote:
Bellegueulle Damien wrote:
--- radeon_driver.c.orig2003-09-21 12:39:25.952390342 +0200
+++ radeon_driver.c2003-09-21 12:27:08.0 +0200
@@ -1058,7 +1058,7 @@
info->PanelPwrDly = RADEON_BIOS16(tmp+44);
if (info->PanelPwrDly > 200
Bellegueulle Damien wrote:
--- radeon_driver.c.orig2003-09-21 12:39:25.952390342 +0200
+++ radeon_driver.c 2003-09-21 12:27:08.0 +0200
@@ -1058,7 +1058,7 @@
info->PanelPwrDly = RADEON_BIOS16(tmp+44);
if (info->PanelPwrDly > 2000 || info->PanelPwrDly < 0)
Michel Dänzer wrote:
On Mon, 2003-09-22 at 12:37, Keith Whitwell wrote:
CVSROOT:/cvsroot/dri
Module name:xc
Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/
Changes by: [EMAIL PROTECTED] 03/09/22 03:37:10
Kendall Bennett wrote:
Jon Smirl <[EMAIL PROTECTED]> wrote:
I think this means you are going to have to rewrite the
drivers/dri/chip and the drivers/dri/chip/server directories.
Yes, it would seem that way.
This is worse than what happed with the original embedded Mesa. In
the original embed
José Fonseca wrote:
This Wiki stuff is really powerfull: I've been adding content into the
Wiki from all those dri-devel posts I have flagged (since long ago).
See http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges
It's really very easy and quick to add stuff - either you edit on the
brows
Ian Romanick wrote:
I'm making the change I mentioned earlier to the way screens / contexts
/ drawables are created by the driver. In doing so I came across some
very curious code in driCreateContext (in lib/GL/dri/dri_util.c). Early
in the function there is an if-statement that begins 'if
(!
Mike A. Harris wrote:
On Mon, 15 Sep 2003, Michel [ISO-8859-1] D?nzer wrote:
IMHO it should be documented somewhere however unless it's
considered a developer only option. If it's developer-only
perhaps it should be only enabled for debug builds?
It's not developer only, but it's not for John
José Fonseca wrote:
On Sun, Sep 14, 2003 at 02:47:16PM -0700, Jon Smirl wrote:
I thought we were moving to http://dri.freedesktop.org/, why not use the wiki
there?
I knew about the CVS but I didn't knew anything regarding moving the DRI
website.
At this stage we're just moving cvs. Other stuff
Did this get resolved? I'm more than happy to commit the patch.
Not really. I never heard anything from Leif about my issue with the
patch. I suspect that it won't be a problem, though. I've yet to hear
of any use having problems with the patch applied. At this point, we
may as well appl
Ian Romanick wrote:
Roland Scheidegger wrote:
You need this patch
http://sourceforge.net/mailarchive/forum.php?thread_id=2054806&forum_id=7177
for nwn to work (unless you're using the beta 3 client or older, you
definitely need it for 1.29, haven't checked for 1.30 if it's still
needed). Unfor
Alex Deucher wrote:
looks like the post size limit ate my first attempt to post this.
Anyway, I was finally able to access DRI cvs (from
dri.freedesktop.org), so I pulled the latest tree and created a radeon
mergedfb patch against it. I've done some testing and it seems to work
fine. The patch o
Linus Torvalds wrote:
On Mon, 8 Sep 2003, Jon Smirl wrote:
I think I have tracked this down to the DRM drivers in the kernel not matching
the ones in DRI CVS. Some of the structures in the initialization IOCTL have
changed which caused one of the ring pointers to initialize to zero instead of
wha
Linus Torvalds wrote:
On Tue, 9 Sep 2003, Linus Torvalds wrote:
I can do a new merge [ ... ]
Is the "dri.freedesktop.org" tree up-to-date? Nothing has happened on it
lately, and I wonder if people are still using the old one for
development?
In the meantime, I could add you to the sf developer
Jon Smirl wrote:
I think I have tracked this down to the DRM drivers in the kernel not matching
the ones in DRI CVS. Some of the structures in the initialization IOCTL have
changed which caused one of the ring pointers to initialize to zero instead of
what it needed. The minor version number prob
Felix Kühling wrote:
I think the idea is that you mirror the entire CVS repository with
cvsup. Then you can do any read-only cvs operations on the local copy of
the repository. That includes merging branches in a working copy. For
commiting you still have to use the remote repository, though.
So
Eric Anholt wrote:
On Thu, 2003-09-04 at 03:55, Felix Kühling wrote:
On Wed, 03 Sep 2003 17:04:59 -0700
Eric Anholt <[EMAIL PROTECTED]> wrote:
On Wed, 2003-09-03 at 01:46, Keith Whitwell wrote:
Thomas Emmel wrote:
On Tue, 2003-09-02 at 19:40, Martin Spott wrote:
Thomas Emmel &
Keith Whitwell wrote:
Adam K Kirchhoff wrote:
And as of this morning, I'm still getting stalled on locks on the *exact*
same file as yesterday morning.
This is one of those cvs problems people talk about. You have to report
the file to the SF admins via the website and they'll go
Adam K Kirchhoff wrote:
And as of this morning, I'm still getting stalled on locks on the *exact*
same file as yesterday morning.
This is one of those cvs problems people talk about. You have to report the
file to the SF admins via the website and they'll go & manually remove the
lock. They're
Mike A. Harris wrote:
On Wed, 3 Sep 2003, Alan Hourihane wrote:
Havoc, your comment on pserver being like telnet isn't really applicable,
anon only pserver is as secure as any anon only service, I wouldn't even
think about using non-anon pserver but I don't think DRI will ever need
such a thing..
Mike Mestnik wrote:
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
On Sat, 2003-08-30 at 18:27, Mike Mestnik wrote:
--- Michel Dnzer <[EMAIL PROTECTED]> wrote:
On Wed, 2003-08-27 at 18:43, Mike Mestnik wrote:
I have something to add to this. Recently I tested gatos drivers going
from dri to gat
Keith Packard wrote:
Around 9 o'clock on Sep 3, Keith Whitwell wrote:
It seems like anon cvs is something that causes project-hosting sites some
discomfort... freedesktop.org doesn't have it in place right now, for instance.
Freedesktop doesn't have any "real" CVS
Ian Romanick wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
Who is building the binary snapshots these days? We need to start
(and should have started a long time ago) including libGL.so in the
snapshots.
Hmm, we've tried to ensure up until now that the drivers would work
with exi
Larry McVoy wrote:
On Wed, Sep 03, 2003 at 04:29:12PM +0100, Keith Whitwell wrote:
I'm not sure that anyone is asking you to use it. What's wrong with the
people who want to use BK use BK and the people who want to use CVS use
CVS?
Primarily the difficulty of creating an automat
Ian Romanick wrote:
[EMAIL PROTECTED] wrote:
Hello
Hello. In the future, please try to include line-breaks in your
messages. It makes them *much* easier to read. Thanks. :)
I am running xfree86 4.3.0 with the ATI 128 drivers from 2nd Sept. I
am trying to run Medal of Honor Allied Assault
Larry McVoy wrote:
On Wed, Sep 03, 2003 at 12:59:43PM +0200, Michel D?nzer wrote:
On Tue, 2003-09-02 at 23:57, Jon Smirl wrote:
-- Michel Dnzer <[EMAIL PROTECTED]> wrote:
I have been using both for a year and BK is simply much better than CVS.
I know bk is the best version control system in th
Larry McVoy wrote:
On Wed, Sep 03, 2003 at 12:59:43PM +0200, Michel D?nzer wrote:
On Tue, 2003-09-02 at 23:57, Jon Smirl wrote:
-- Michel Dnzer <[EMAIL PROTECTED]> wrote:
I have been using both for a year and BK is simply much better than CVS.
I know bk is the best version control system in th
Thomas Emmel wrote:
On Wed, 2003-09-03 at 13:53, Keith Whitwell wrote:
Hmm, after looking at your screenshots, this seems like a seperate, unrelated
problem.
What happens if you set the following environment variables:
R200_NO_VTXFMT=t
R200_NO_TCL=t
Keith
R200_NO_VTXFMT=t
Havoc Pennington wrote:
On Wed, Sep 03, 2003 at 12:57:30PM +0100, Dave Airlie wrote:
Havoc, your comment on pserver being like telnet isn't really applicable,
anon only pserver is as secure as any anon only service, I wouldn't even
think about using non-anon pserver but I don't think DRI will eve
Havoc Pennington wrote:
Hi,
I'm not sure freedesktop.org can host anoncvs, though it's possible we
could for DRI. I know GNOME, KDE, Mozilla, and other huge projects'
anoncvs would require more load than freedesktop.org server can
handle. DRI anoncvs traffic may be smaller.
However, we do plan to
Thomas Emmel wrote:
On Wed, 2003-09-03 at 11:12, Thomas Emmel wrote:
Back to my problem...
On Tue, 2003-09-02 at 17:24, Keith Whitwell wrote:
Is it correct that your application is using 1-dimensional textures and vertex
arrays? This is a little-exercised aspect of the driver, but it
Thomas Emmel wrote:
On Wed, 2003-09-03 at 11:12, Thomas Emmel wrote:
Back to my problem...
On Tue, 2003-09-02 at 17:24, Keith Whitwell wrote:
Is it correct that your application is using 1-dimensional textures and vertex
arrays? This is a little-exercised aspect of the driver, but it
Martin Spott wrote:
Thomas Emmel <[EMAIL PROTECTED]> wrote:
and this message means that the CVS-server is full.
I think this was mentioned before two days ago.
Some days before I had the problem that the download hangs in
xc/xc/util/patch infinitely. Now I tried to download completely
from scrat
Thomas Emmel wrote:
On Tue, 2003-09-02 at 19:40, Martin Spott wrote:
Thomas Emmel <[EMAIL PROTECTED]> wrote:
and this message means that the CVS-server is full.
I think this was mentioned before two days ago.
Some days before I had the problem that the download hangs in
xc/xc/util/patch infinit
Larry McVoy wrote:
From: Linus Torvalds <[EMAIL PROTECTED]>
To: Jon Smirl <[EMAIL PROTECTED]>
Subject: Re: Sourceforge CVS, was Re: [Dri-devel] radeon error
On Tue, 2 Sep 2003, Jon Smirl wrote:
Having used CVS and BitKeeper, BitKeeper is way better.
I will just add a big "Amen, Brother!" to that.
Ian Romanick wrote:
Jon Smirl wrote:
The BitKeeper people have said they would love to be the host for
DRI/Mesa
source. We would still leave bug tracking, web pages, etc at
Sourceforge. Only
the source code would move.
I'm not 100% positive, but I believe that if this happens I will no
longer
Michel Dänzer wrote:
On Tue, 2003-09-02 at 23:17, Jon Smirl wrote:
--- Michel Dnzer <[EMAIL PROTECTED]> wrote:
On Tue, 2003-09-02 at 19:37, Jon Smirl wrote:
The BitKeeper people have said they would love to be the host for DRI/Mesa
source.
I strongly object to this, I won't take part in developm
If we just want to get rid of sf.net, CVS on freedesktop.org would
probably be a good place to go. Plus, then we could set up cvsup, which
offers fast checkouts/updates for folks and repository mirroring for
developers.
That was my original thought/hope -- a better free cvs host. sf.net is
tank
Linus Torvalds wrote:
On Tue, 2 Sep 2003, Jon Smirl wrote:
Having used CVS and BitKeeper, BitKeeper is way better.
I will just add a big "Amen, Brother!" to that.
Yes, BitKeeper has license issues, and some people won't touch it. But
there are CVS/SVN gateways for that, and the kernel people (w
Thomas Emmel wrote:
I would do so if I could download the source.
CVS is currently unusable for normal users.
Error is:
cvs [server aborted]: cannot make directory KSC5601: No space left on
device
and this message means that the CVS-server is full.
OK, this was supposed to have been fixed in Augus
Eric Anholt wrote:
As some of you have heard, I'm working on getting the SiS DRI working
again. It's been quite a lot of work, particularly given my lack of
knowledge about OpenGL or the structure of the client drivers. However,
I am to the point where I can run several mesa demos (gears, fire,
t
Michel Dänzer wrote:
On Sat, 2003-08-30 at 13:06, Jouni Tulkki wrote:
Is there a way to make moving images and textures to video memory faster?
Currently I'm using Radeon 9500 Pro and AGP 8x.
Curious, how do use AGP without the DRI being enabled? :) (And how 8x
when the X server only supports u
Eric Anholt wrote:
On Sun, 2003-08-31 at 03:47, Michael Schreckenbauer wrote:
Am Samstag, 30. August 2003 00:02 schrieb Eric Anholt:
My current diff is at:
http://people.freebsd.org/~anholt/dri/files/sis-14.diff
It's against DRI CVS. Should work fine on Linux/FreeBSD, with or
without sisfb. I h
Thomas,
Is it correct that your application is using 1-dimensional textures and vertex
arrays? This is a little-exercised aspect of the driver, but it shouldn't too
hard to fix up. I'll try and rig up something here that exercises the problem.
In the meantime, what does the following patch do
Linus Torvalds wrote:
Ok, this is pretty off-topic, but I'm wondering what the status is for
open-source support of 3D-capable drivers for such studly monitors as the
IBM T221.
Yes, it's still expensive as hell, but it isn't nearly as bad as it was a
few years ago when it was very limited availabil
Dave Airlie wrote:
driUpdateTextureLRU( (driTextureObject *) t ); /* XXX: should be locked */
I've taken this approach as well.. but should it be locked? if so how? is
the i830 correct should I try to do something similiar?
Because this function call modifies the global (ie shared memory) LRU, it
s
Thomas Emmel wrote:
Hi together,
recently I sended an email to Keith who directed me to this list.
My application (ABAQUS, see below for details) crashes if I use
your r200-dri-module. The particular error is:
r200_maos_arrays.c:298: emit_vector: Assertion `0' failed.
and the spplication died.
Ah,
Alex Deucher wrote:
there is a driver option in your config file to choose how much ram you
want to use for your adapter. I don't remember what it is off hand.
VideoRam 32000
or some other number
Keith
---
This sf.net email is sponsored by:T
Dave Airlie wrote:
In i810_dri.h there is a warning..
/* WARNING: Do not change the SAREA structure without changing the kernel
* as well */
for texmem I want to apply the same patch as..
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_dri.h.d
Dave Airlie wrote:
Okay I've gotten around to updating the i810 driver to texmem interface...
http://www.skynet.ie/~airlied/patches/dri/i810_texmem.diff
I've a couple of issues perhaps someone can help with:
1. In texstate.c UpdateTexUnit for most drivers (except i830) the
following appears:
dri
Moritz Muehlenhoff wrote:
Michel Dänzer wrote:
On Sat, 2003-08-16 at 21:49, Moritz Muehlenhoff wrote:
One more thing that may influence the performance is your screen
resolution and refresh rate as the refresh consumes memory bandwidth.
It's just plain 72 Hz, nothing special.
IIRC there used to
Jon Smirl wrote:
I figured out this this works:
insmod ./r128.ko drm_opts=debug:on
But won't it be in the spirt of 2.6 module parameters
if
insmod ./r128.ko debug=on
I've never used these options. How much use do they get generally? I'd be
just as happy to remove the code.
Keith
--
Ville Syrjälä wrote:
On Thu, Aug 14, 2003 at 06:23:12PM +0100, Keith Whitwell wrote:
Ville Syrjälä wrote:
The only issue I found with glean right now is that hw.blend_func isn't
properly initialized and if an app calls glBlendFunc( GL_ONE, GL_ZERO );
the actual function will be GL_ZERO,GL
[EMAIL PROTECTED] wrote:
On Wed, Jul 30, 2003 at 11:40:24PM -0700, Ian Romanick wrote:
Haven't heard anything from you in awhile. How are things going on the
patch? :)
Also, have you given any consideration to supporting NV_point_sprite?
The way that you're implementing point sizes is very sim
Ville Syrjälä wrote:
On Wed, Aug 13, 2003 at 05:54:21AM -0600, Keith Whitwell wrote:
Ville Syrjälä wrote:
I just commited a fix for the projective texturing fallback to the mga
driver.
While I was trying to figure out what was going on I had a look at
the r128 driver. But looking there didn&#
Ville Syrjälä wrote:
From mgastate.c:
\note the fully opaque pattern (0x) has been disabled in order
to work around a conformance issue.
Can anyone tell me what the issue actually is?
Conform does things like turn on stipple but set an all-ones pattern to ensure
that triangle rasterization is
Ville Syrjälä wrote:
I just commited a fix for the projective texturing fallback to the mga
driver.
While I was trying to figure out what was going on I had a look at
the r128 driver. But looking there didn't help as it seems to require the
same fix. Should I do this fix for all affected drivers or
Jon Smirl wrote:
Thanks for taking the time to respond to this. I am
starting to understand why so few people choose to
work on the OpenGL code. Much of what you need to
know is either undocumented or restricted by the
hardware vendors.
You probably want to read the glx specification, which you
Ian Romanick wrote:
Ville Syrjälä wrote:
This patch implements these extensions:
GL_ARB_texture_env_combine
GL_EXT_texture_env_combine
GL_ARB_texture_env_crossbar
I was thinking about this earlier today, and I think I know how we can
improve performance...a lot. If my understanding of how a
Ian Romanick wrote:
Ian Romanick wrote:
I'm also having second thoughts about allowing drivers to add function
calls to the GLX dispatch table. This is a global table that has no
way to identify the "owner" of a dispatch function. This
functionality is currently only used by a single feature
Ian Romanick wrote:
Keith Whitwell wrote:
I'm happy to drop these once we have identified & implemented a
suitable replacement.
There are two ways to go on this. One way is to make a new
GLX_MESA_memory_allocate extension that just extends the existing
glXAllocateMemoryNV, glXFre
Ian Romanick wrote:
Michel Dänzer wrote:
On Tue, 2003-07-29 at 22:41, Ian Romanick wrote:
1. I don't like the hard-coding of 2*1024*1024 as the size of the
indirect buffers. This was copied directly from the R200 driver, but
I don't like it. We may want to change the size of this buffer at
s
601 - 700 of 1643 matches
Mail list logo
