On 2002.06.12 03:49 Leif Delgass wrote:
On Tue, 11 Jun 2002, José Fonseca wrote:
...
Please, let's not discuss this further. I think we both agree that
using a
variable is the best wat to go, isn't it?
Each and every processor cycle must be precisely documented and accounted
for!
Title: alpha
Future DVD Absolutely Free!!! 3 hrs!
The Porn Star
Edition! Future Works Interactive Demo Disk absolutely FREE! No purchase
necessary!
CLICK
HERE
Best Selling New Celebrity
DVD VHS: Trench's Naturally Naughty Porno Movie!!! RAP STAR TURNS
HARDCORE PORN STAR! Trench
On Tue, 11 Jun 2002, Keith Whitwell wrote:
Date: Tue, 11 Jun 2002 10:56:16 +0100
From: Keith Whitwell [EMAIL PROTECTED]
To: dri-devel [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii; format=flowed
List-Id: dri-devel.lists.sourceforge.net
Subject: tcl branch merge
Although we still
On Mon, Jun 10, 2002 at 07:37:19PM +0100, José Fonseca wrote:
On 2002.06.10 18:32 Ville Syrjälä wrote:
Here's my understanding of the situation. Someone more enlightened should
correct me if I'm wrong.
On Mon, Jun 10, 2002 at 04:22:11PM +, Gareth Knight wrote:
I am interested in
Keith Whitwell wrote:
Although we still have a couple of bugs a lockup on the tcl branch,
the situation is in general better than what's on the trunk I'd like
to get that code merged now. This will also help get the 8500 branch
started.
OK. It's merged.
Keith
On 2002.06.12 17:01 Keith Whitwell wrote:
Keith Whitwell wrote:
Although we still have a couple of bugs a lockup on the tcl branch,
the situation is in general better than what's on the trunk I'd like
to get that code merged now. This will also help get the 8500 branch
started.
José Fonseca wrote:
On 2002.06.12 17:01 Keith Whitwell wrote:
Keith Whitwell wrote:
Although we still have a couple of bugs a lockup on the tcl branch,
the situation is in general better than what's on the trunk I'd
like to get that code merged now. This will also help get the 8500
Two quick questions :-)
First, can anyone tell me if the issues with tuxkart and the Radeon driver
from the TCL branch (well, now the trunk) have been fixed?
Secondly, does anyone regularly go through the bug reports on sourceforge?
There are a huge number of bug reports, some from over two
On Wed, Jun 12, 2002 at 12:57:37PM -0400, Adam K Kirchhoff wrote:
Two quick questions :-)
First, can anyone tell me if the issues with tuxkart and the Radeon driver
from the TCL branch (well, now the trunk) have been fixed?
Keith fixed a problem with line loops that was causing crashes.
On 2002.06.12 17:57 Adam K Kirchhoff wrote:
Two quick questions :-)
First, can anyone tell me if the issues with tuxkart and the Radeon
driver
from the TCL branch (well, now the trunk) have been fixed?
Secondly, does anyone regularly go through the bug reports on
sourceforge?
There
José Fonseca wrote:
On 2002.06.12 17:57 Adam K Kirchhoff wrote:
Two quick questions :-)
First, can anyone tell me if the issues with tuxkart and the Radeon
driver
from the TCL branch (well, now the trunk) have been fixed?
Secondly, does anyone regularly go through the bug reports on
José Fonseca wrote:
On 2002.06.12 17:57 Adam K Kirchhoff wrote:
Two quick questions :-)
First, can anyone tell me if the issues with tuxkart and the Radeon
driver
from the TCL branch (well, now the trunk) have been fixed?
Secondly, does anyone regularly go through the bug reports on
On 2002.06.12 18:42 Keith Whitwell wrote:
...
I'm just in general not a big fan of the bug tracker. I've got a bunch
of bugs that I can choose from at any time without having to go through
some web form that requires me to log in and wait for slow queries. It
doesn't give *me*
On 2002.06.12 18:49 Keith Whitwell wrote:
...
I totally disagree here...
The dri-users list was founded on the idea that there might be a class
of 'power users' out there who would altruistically help newbies get
their setup working so that 'real developers' could concentrate on
On 2002.06.12 19:31 Keith Whitwell wrote:
José Fonseca wrote:
...
To separate the development issues from, .e.g, installation problems. I
personally wouldn't like to have my dri-devel mbox full with cryies for
help - if that happened I effectively would make my procmail seperate
Howzit Jens?
3 Parts to this email.
1.) MK II:
_
\
+-+ |
| X11/OpenGL Based Application | |
| (Using 3D Direct Rendering) | |
On Wed, Jun 12, 2002 at 07:31:29 +0100, Keith Whitwell wrote:
Yeah! Let's burn Rome! ;o)
OK, maybe I'm getting carried away.
But as I see it, there aren't many people in total on dri_devel+dri_users.
The only people who can really answer dri_users questions are on dri_devel
anyway.
I personally think we shouldn't do this, but I'll go for what the majority
decides - after all it's what's the majority will do in the end that will
really matter. So, speak up now, or forever remain quiet...
I think if someone posts a good bug report, maybe even 1/2 a fix and is
willing
On Wednesday 12 June 2002 19:49, Keith Whitwell wrote:
The dri-users list was founded on the idea that there might be a class of
'power users' out there who would altruistically help newbies get their
setup working so that 'real developers' could concentrate on loftier ideas.
That class of
Peter Soetens (Kaltan) wrote:
On Wednesday 12 June 2002 19:49, Keith Whitwell wrote:
The dri-users list was founded on the idea that there might be a class of
'power users' out there who would altruistically help newbies get their
setup working so that 'real developers' could
On Wed, Jun 12, 2002 at 02:28:45 -0600, Jens Owen wrote:
Peter Soetens (Kaltan) wrote:
On Wednesday 12 June 2002 19:49, Keith Whitwell wrote:
The dri-users list was founded on the idea that there might be a class of
'power users' out there who would altruistically help newbies get
On Wednesday 12 June 2002 20:53, Alan Hourihane wrote:
[-]
We really need to clean up the stuff on SF now. Probably about 90%
don't even apply now, or should at least be re-tested.
Yes, let's start with that.
There are even several bugs for which the sender asked for closing but never
Keith Whitwell wrote:
Keith Whitwell wrote:
Although we still have a couple of bugs a lockup on the tcl branch,
the situation is in general better than what's on the trunk I'd like
to get that code merged now. This will also help get the 8500 branch
started.
OK. It's merged.
I
j == j r fonseca Jos writes:
j In theory, dri-devel should be mainly for communication between all
j developers and beta-testers. The dri-users should be for everybody else.
j This is what I see in many other projects and it works quite well.
Giving the stage of the (e.g. Radeon
For what it's worth, it runs great now here. I've actually finished a
game or two without any lockups.
Adam
On Wed, 12 Jun 2002, Michael wrote:
On Wed, Jun 12, 2002 at 12:57:37PM -0400, Adam K Kirchhoff wrote:
Two quick questions :-)
First, can anyone tell me if the issues with
Dieter Nützel wrote:
On Wednesday 12 June 2002 20:53, Alan Hourihane wrote:
[-]
We really need to clean up the stuff on SF now. Probably about 90%
don't even apply now, or should at least be re-tested.
Yes, let's start with that.
There are even several bugs for which the sender asked
On Mon, 10 Jun 2002, Linus Torvalds wrote:
If you have an AMD system and have seen problems with GART usage, and
are willing to test out stuff, please give this a try. I'd love to hear
actual user reports about whether this actually solves any problems.
The DRI lockup on switching console
On 2002.06.12 21:53 Alan Hourihane wrote:
On Wed, Jun 12, 2002 at 02:28:45 -0600, Jens Owen wrote:
...
I'm certainly as guilty as anyone for letting the cruft build up in the
SF bug tracker. However, from a TG commercial perspective, I will need
to closely track all bugs specifically
Keith Whitwell wrote:
OK, maybe I'm getting carried away.
But as I see it, there aren't many people in total on dri_devel+dri_users.
The only people who can really answer dri_users questions are on dri_devel
anyway. Why have two lists?
There aren't a great number of dri_users
There aren't a great number of dri_users questions anyway and a good=20
percentage of them probably should be on dri_devel as it stands now (they=
're=20
proper bugs, or whatever).
So, I guess I still think the second list:
- doesn't serve it's intended audience well
-
Hi.
I've recently compiled new code with tcl-branch merged. I've encountered
problem when rendering into front buffer and having double-buffered
visual. It seems that glDrawBuffer must be called ech time after
radeonUpdatePageFlipping or the app starts rendering into back buffer.
My guess is
Brian Paul wrote:
Keith Whitwell wrote:
Keith Whitwell wrote:
Although we still have a couple of bugs a lockup on the tcl branch,
the situation is in general better than what's on the trunk I'd like
to get that code merged now. This will also help get the 8500 branch
started.
Jacek Rosik wrote:
Hi.
I've recently compiled new code with tcl-branch merged. I've encountered
problem when rendering into front buffer and having double-buffered
visual. It seems that glDrawBuffer must be called ech time after
radeonUpdatePageFlipping or the app starts rendering into
And the below trunk file should look like this, again:
xc/xc/lib/GL/mesa/src/drv/Imakefile
SUBDIRS = common DriDrivers
_NOT_
SUBDIRS = common radeon
Done. Thanks.
Keith
___
Sponsored by:
ThinkGeek at
Dieter Nützel wrote:
On Wednesday 12 June 2002 20:53, Alan Hourihane wrote:
[-]
We really need to clean up the stuff on SF now. Probably about 90%
don't even apply now, or should at least be re-tested.
Yes, let's start with that.
There are even several bugs for which the sender asked
I've just noticed some combinations of 2 apps running at once causes
hangs (well, I had glxgears minimised and had forgotten and ran q3)
A wild stab in the dark.
When we currently send a cmd buffer something like this :-
app 1 packet 1 app2 packet 1
5 (LOAD_VBPNTR)
It would appear that AGP mode 1x is used by default always unless
the AGPmode option is specified in the config file. (Correct me
if I'm not completely correct with that).
I'm wondering if the default can be changed to be the fastest
sane mode supported by the hardware and/or configured by
On Wed, Jun 12, 2002 at 08:35:15PM -0400, Mike A. Harris wrote:
It would appear that AGP mode 1x is used by default always unless
the AGPmode option is specified in the config file. (Correct me
if I'm not completely correct with that).
I'm wondering if the default can be changed to be
From: Mike A. Harris [EMAIL PROTECTED]
Date: Wed, 12 Jun 2002 20:35:15 -0400 (EDT)
It would appear that AGP mode 1x is used by default always unless
the AGPmode option is specified in the config file. (Correct me
if I'm not completely correct with that).
I'm wondering if
On Wed, 12 Jun 2002, David S. Miller wrote:
Date: Wed, 12 Jun 2002 18:08:37 -0700 (PDT)
From: David S. Miller [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Content-Type: Text/Plain; charset=us-ascii
Subject: Re: [Dri-devel] Default AGP mode
From: Mike A. Harris [EMAIL
--- José Fonseca [EMAIL PROTECTED] wrote:
On 2002.06.12 18:49 Keith Whitwell wrote:
...
I totally disagree here...
That class of power users haven't really emerged, if anything it is the
power users who are crying for help in the blackness of dri-users, as
everyone else
--- David Willmore [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
OK, maybe I'm getting carried away.
But as I see it, there aren't many people in total on dri_devel+dri_users.
The only people who can really answer dri_users questions are on dri_devel
anyway. Why have two lists?
I have an ATI Radeon LE (which is pretty much the same
card as the ATI Radeon DDR but only with 32megs of DDR
ram not 64).
Specifically:
Linux misato 2.4.19-pre10 #1 Tue Jun 4 04:44:29 EDT
2002 i686 unknown
using:
XFree86 Version 4.2.0 (DRI trunk) / X Window System
(protocol Version 11,
Mike A. Harris wrote:
On Wed, 12 Jun 2002, David S. Miller wrote:
Date: Wed, 12 Jun 2002 18:08:37 -0700 (PDT)
From: David S. Miller [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Content-Type: Text/Plain; charset=us-ascii
Subject: Re: [Dri-devel] Default AGP mode
Well, I had a Eureka! moment and figured out the problem with 2D accel,
which was also the cause of the signal 11 on server shutdown. Hidden in
atiaccel.c there is a second initialization of the framebuffer manager
that was causing XAA to use the entire offscreen area (including our back,
depth
From: Jeff Hartmann [EMAIL PROTECTED]
Date: Wed, 12 Jun 2002 21:57:31 -0500
Actually, its most safe to default to AGP mode 1x. If we aren't
switching modes correctly there is a bug in that agp driver, and I'd
like to know about it.
Try to enable 4X in BIOS of SiS Athlon
From: Mike A. Harris [EMAIL PROTECTED]
Date: Wed, 12 Jun 2002 21:39:23 -0400 (EDT)
Basically, someone has asked for me to default AGPMode to 4 in
our config file, which I thought was absolutely crazy. The claim
is that AGP defaulted to 1x, but changing it to 4x sped things
47 matches
Mail list logo
