Hi,
I attached a first attempt on a patch that makes client-side extensions
aware of multiple screens and will allow extensions to be enabled
conditionally by the drivers. This is a result of the thread
Observations about dynamic extension registration. It compiles but the
drivers aren't changed
On Thu, 31 Jul 2003 10:12:47 -0600
Brian Paul [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
Felix Kühling wrote:
I observed that glXQueryExtensionsString calls glXInitialize first which
in turn loads and initializes the dri drivers (calls their createScreen
On Tue, 29 Jul 2003 16:01:22 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
On Tue, 29 Jul 2003 13:58:58 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Do the __driRegisterExtensions functions in the drivers rely on being
called during
On Wed, 30 Jul 2003 09:20:28 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
I see:
C SPECIFICATION
const char * glXQueryExtensionsString( Display *dpy,
int screen )
I don't mean what the GLX specification says
Hi,
as I'm going to clean up vsync related stuff on the config-0-0-1-branch
I read the code for dynamic glx extension registration in
xc/lib/GL/dri/dri_glx.c and xc/lib/GL/glx/glxextensions.[ch]. I stumbled
over this comment in front of __glXRegisterExtensions:
** In older versions of libGL
On Tue, 29 Jul 2003 13:58:58 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
as I'm going to clean up vsync related stuff on the config-0-0-1-branch
I read the code for dynamic glx extension registration in
xc/lib/GL/dri/dri_glx.c and xc/lib/GL/glx/glxextensions
On Mon, 28 Jul 2003 11:05:57 -0700
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
I believe this solution is very flexible and keeps the implementation
complexity small as the drivers don't need to parse symbolic values from
configuration files. Comments?
Yes. This looks
Hi,
I promised more details about a new option type enum in the
configuration scheme. Basically it is jut a special case of an integer
that _requires_ a valid attribute in the driver's XML document in
order to guarantee enumerability. Furthermore individual values _can_
(but don't need to) be
On 26 Jul 2003 00:37:31 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On Sat, 2003-07-26 at 00:27, Felix Kühling wrote:
On 26 Jul 2003 00:12:05 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On a related note, I think use_irqs shouldn't have an impact on the
vblank code, it's about
On 25 Jul 2003 22:31:24 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2003-07-25 at 22:22, Felix Kühling wrote:
On 25 Jul 2003 16:24:36 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
libGL error:
Warning in /home/michdaen/.drirc line 1, column 0: unknown element: dri.
libGL
On 26 Jul 2003 00:12:05 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2003-07-25 at 22:40, Felix Kühling wrote:
On 25 Jul 2003 22:31:24 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2003-07-25 at 22:22, Felix Kühling wrote:
On 25 Jul 2003 16:24:36 +0200
Michel
Hi,
I found another problem in t_dd_dmatmp2.h in render_quads_elts. The
attached patch fixes garbage on the quakeforge console and with some
particle effects. One more piece for Keiths dmatmp2 cleanup.
Regards,
Felix
__\|/_____ ___ -
Hi all,
I just uploaded a first version of a graphical configuration tool to my
home page.
http://fxk.de.vu/projects_cur_en.html
There probably still a lot of work to do and probably many bugs to fix.
But I want to make it available as soon as possible in order to get more
feedback on the
On Sun, 13 Jul 2003 17:13:15 +0200
Felix Kühling [EMAIL PROTECTED] wrote:
Hi all,
I just uploaded a first version of a graphical configuration tool to my
home page.
http://fxk.de.vu/projects_cur_en.html
There probably still a lot of work to do and probably many bugs to fix.
Yup
Hi,
I've been wondering about keywords in Imakefiles that look like CVS
keywords. Examples from xc/programs/Imakefile:
XCOMM $Xorg: Imakefile,v 1.4 2000/08/17 19:47:01 cpqbld Exp $
XCOMM $XFree86: xc/programs/Imakefile,v 3.53 2002/11/20 04:43:50 dawes Exp $
Of course they are not documented in
On Tue, 1 Jul 2003 11:18:02 -0700 (PDT)
Jorge Luis Williams [EMAIL PROTECTED] wrote:
(Moderator please ignore duplicate message -- I sent it from the wrong
account -- sorry)
Hello,
I have a Radeon 9000 64 MB DDR AGP card and I've been running it on a
2Ghz Intel Pentium IV machine
On Tue, 24 Jun 2003 22:01:47 +1000
Damien Miller [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
I have some questions about OS specific ways to find out the name of a
running programme outside function main.
extern chat *__progname;
works on OpenBSD, NetBSD and Linux.
Thanks
On Tue, 24 Jun 2003 13:32:22 +0200
Felix Kühling [EMAIL PROTECTED] wrote:
[snip]
2) (How) can one check for specific *BSD versions via #if ?
I found some more info on http://predef.sourceforge.net/preos.html,
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd
Hi,
I have some questions about OS specific ways to find out the name of a
running programme outside function main. The following section verbosely
introduces the problem and what information I found so far. You may just
skip down to Questions. I hope someone can fill in the blanks.
The new
On 23 Jun 2003 12:17:26 +0200
Michel Dänzer [EMAIL PROTECTED] wrote:
On Sat, 2003-06-21 at 14:14, Andreas Stenglein wrote:
[snip]
+ /* question: shouldn't the following be controlled by the
kernelmodule */
+ /* and/or Xserver-configuration if it can crash the card? */
else if
On Mon, 16 Jun 2003 10:21:20 -0700 (PDT)
Alex Deucher [EMAIL PROTECTED] wrote:
I've looked through the code and all the DRILock() and DRIUnlock() seem
to be right. the only things that stands out as potentially suspicious
is in RADEONAdjustFrame():
void RADEONAdjustFrame(int scrnIndex, int
Hi,
I thought this would be a good time to summarize the status of the
config-0-0-1-branch. I believe it's ready to get some testing. If
someone is interested in porting other drivers to the new configuration
infrastructure, go ahead. Otherwise I'll do so as time permits. It's
actually quite
Hi,
even with LIBGL_SYNC_REFRESH I get bad tearing with quake2. I looked
into the source a bit and now I'm scratching my head about this
question: Does waiting for a vblank do anything useful if you havn't
flushed the 3D hardware graphics pipeline before? I believe the driver
should call
On Thu, 05 Jun 2003 16:51:27 -0600
Brian Paul [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
even with LIBGL_SYNC_REFRESH I get bad tearing with quake2. I looked
into the source a bit and now I'm scratching my head about this
question: Does waiting for a vblank do anything useful
Hi,
I'm trying to integrate xdriinfo into the DRI tree. My first idea was to
add it under xc/programs/xdriifno. But none of the subdirs of
xc/programs are compiled except Xserver if BuildServersOnly is set (as
in the default DRI host.def). So I thought
xc/programs/Xserver/hw/xfree86/xdriinfo
How are performance boxes enabled in the radeon driver? Apperently
setting rmesa-boxes to 1 is not enough. There is a variable
dev_priv-do_boxes in the kernel driver. But it is initialized to 0 in
radeon_do_init_cp and not changed anywhere else. Am I missing something?
Regards,
Felix
On Fri, 30 May 2003 22:03:20 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
How are performance boxes enabled in the radeon driver? Apperently
setting rmesa-boxes to 1 is not enough. There is a variable
dev_priv-do_boxes in the kernel driver. But it is initialized to 0
Hi,
I have a working version of xdriinfo (the tool that dumps the drivers'
configuration information) that I'd like to commit somewhere in the
config-0-0-1-branch. I suppose xc/programs/... would be the right place.
It's just that this would be the only thing in xc/programs besides the
XServer
On Tue, 25 Mar 2003 20:02:24 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Gareth Hughes wrote:
Andreas Stenglein wrote:
Yes, at least the part with GL_TRIANGLE_STRIP.
In case of 0 you can just return 0, no copying is needed.
case 0: return 0; break;
You're going to do
On Mon, 10 Mar 2003 22:23:07 +
José Fonseca [EMAIL PROTECTED] wrote:
[snip]
As I said above this can be done in C++, and without damage to
efficiency.
Imagine you have a TnL abstract class:
class TNL {
// A OpenGL function
virtual void Coord3f(GLfloat x, GLfloat y, GLfloat z) =
On Mon, 10 Mar 2003 23:43:37 +
José Fonseca [EMAIL PROTECTED] wrote:
Jon Smirl,
I took the liberty of CC'ing the lists again as it is a very valid point
you make here.
On Mon, Mar 10, 2003 at 03:17:56PM -0800, Jon Smirl wrote:
[snip]
_cdecl handler(Context* self, sfactor, dfactor)
On Fri, 07 Mar 2003 08:30:56 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Jonathan Thambidurai wrote:
I was looking at the source for the radeon driver and noticed that the
depth buffer is always set to 32 bits if a 24 bpp color depth is
selected. Is this a hardware limitation, or
On Fri, 07 Mar 2003 07:12:44 -0700
Jens Owen [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
[snip]
This is yet another thing that could become a configuration option with
the new configuration scheme. Besides radeon and r200, would this also
be possible with other drivers?
Currently
On Fri, 07 Mar 2003 14:46:00 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
This is yet another thing that could become a configuration option with
the new configuration scheme. Besides radeon and r200, would this also
be possible with other drivers?
Actually, wasn't
On Wed, 5 Mar 2003 10:24:12 -0700
Nicholas Leippe [EMAIL PROTECTED] wrote:
On Wednesday 05 March 2003 12:10 am, Ian Romanick wrote:
Jens Owen wrote:
Jose,
I've been on the road for the last few days, so I haven't had a chance
to express my concern for porting the DRI to C++.
On Wed, 5 Mar 2003 11:54:56 -0700
Nicholas Leippe [EMAIL PROTECTED] wrote:
On Wednesday 05 March 2003 10:54 am, Felix Kühling wrote:
If you use the standard library you have to start worrying about ABI
compatibility issues. How much trouble is it to write C++ code that can
be linked
On Wed, 5 Mar 2003 19:22:39 +
José Fonseca [EMAIL PROTECTED] wrote:
On Wed, Mar 05, 2003 at 06:54:31PM +0100, Felix Kühling wrote:
[snip]
But does C++ use the library behind your back?
AFAIK g++ alway implicitly links with libstdc++.
I don't believe there is any dependency of STL
// /_/ /) just not everything
[EMAIL PROTECTED] \___/ \___/ Uat the same time.
DRI Configuration Infrastructure (Draft)
Revision 1
Felix Kühling [EMAIL PROTECTED], D. Hageman [EMAIL PROTECTED]
05 March 2003
1. Introduction
---
Many proprietary OpenGL implementations
On Mon, 03 Mar 2003 10:38:40 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
Not too many updates this time.
There are a few issues that I really want to discuss work out before
any coding begins.
1. Felix Kuhling asked, basically, how does a process manage the memory
blocks that it has
On Sun, 2 Mar 2003 10:34:35 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Sun, 2 Mar 2003, Andreas Stenglein wrote:
I pulled the powercable, waited, plugged the cable,
startet the box up again and tried without dri:
Xserver recycles well!
I have apparently seen something
On Sun, 02 Mar 2003 12:40:24 -0600
Sean E. Russell [EMAIL PROTECTED] wrote:
Anyway, I'm very pleased that everything is working so well. Thanks for all
of the help, especially from Felix Kühling.
I'm happy to hear that. Though I think Michel Dänzer deserves the credit
better. He knew about
On Fri, 28 Feb 2003 22:13:22 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hello,
I just started working on a revision of the DRI Configuration design doc
based on the feedback I received. As Brian suggested I want to implement
the functionality for acquiring
On Fri, 28 Feb 2003 22:13:22 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hello,
I just started working on a revision of the DRI Configuration design doc
based on the feedback I received. As Brian suggested I want to implement
the functionality for acquiring
On Fri, 28 Feb 2003 04:39:58 +0100
Bernhard Kaindl [EMAIL PROTECTED] wrote:
On Thu, 27 Feb 2003, Jon Smirl wrote:
Long ago I loved the command line. I was an expert at
it. When Window 1.0 came out I got my first exposure
to a mouse. For about a year I wouldn't get one, but
now I can't
On 28 Feb 2003 12:00:48 GMT
Martin Spott [EMAIL PROTECTED] wrote:
Nick Kurshev [EMAIL PROTECTED] wrote:
Image distortion became visible in oct 2002.
This probably was the time when hardware-TCL came into play !?
You could try to set $RADEON_TCL_FORCE_DISABLE to 't' and see if it makes
On 28 Feb 2003 14:02:14 +0100
Michel Dänzer [EMAIL PROTECTED] wrote:
On Fre, 2003-02-28 at 13:30, Felix Kühling wrote:
On 28 Feb 2003 12:00:48 GMT
Martin Spott [EMAIL PROTECTED] wrote:
Nick Kurshev [EMAIL PROTECTED] wrote:
Image distortion became visible in oct 2002
Hello,
I just started working on a revision of the DRI Configuration design doc
based on the feedback I received. As Brian suggested I want to implement
the functionality for acquiring available configuration options in
libGL. I had a look at xc/lib/GL/dri and it looks as if dri_glx.[ch]
would be
On Mon, 24 Feb 2003 21:13:09 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
Michel Dänzer wrote:
On Son, 2003-02-09 at 23:40, Keith Whitwell wrote:
Felix Kühling wrote:
On Sun, 09 Feb 2003 09:53:55 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
diff -u
On Tue, 25 Feb 2003 00:46:36 -0800
David Bronaugh [EMAIL PROTECTED] wrote:
On Mon, 24 Feb 2003 21:13:09 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
What became of this? It seems to fix the flag in bzflag having the wrong
texture with the r200 driver with SW TCL as well.
I
Hello José,
I've been reading a bit about Via's ProSavage chipsets with integrated
Savage4/8 graphics. And I've been thinking to buy a laptop in the near
future, as a debugging aid with DRI and as a toy ;-) and of course for
some work.
Anyway, I have no exact prediction as to when I will buy it,
On Mon, 24 Feb 2003 16:24:17 +0100
[EMAIL PROTECTED] wrote:
I've got an Acer Travelmate a-550 with Via ProSavage PN133 (Twister).
Coul'd U send my the documentation that U read about it? I'm interesting
developing the kernel driver.
Sorry, I didn't mean any technical specifications. I just
On Sat, 22 Feb 2003 15:38:40 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Running into a problem when killing glthreads with Ctrl-C. Normally this
would invoke the release() method and clean up buffers, locks etc.
Unfortunately this doesn't work so well with threads - the release method is
On Fri, 21 Feb 2003 01:36:01 +
José Fonseca [EMAIL PROTECTED] wrote:
Felix, D. Hageman,
On Wed, Feb 19, 2003 at 09:52:47AM +0100, Felix Kühling wrote:
Hello list,
D. Hageman and I have been bouncing a design document for the new
configuration infrastructure back and forth
On Fri, 21 Feb 2003 07:43:24 -0700
Brian Paul [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
On Fri, 21 Feb 2003 01:36:01 +
José Fonseca [EMAIL PROTECTED] wrote:
[snip]
I don't if it is possible at all, but it surely would be nice if we
didn't have to rely on having X access at all
On Thu, 20 Feb 2003 01:49:43 -0600 (CST)
D. Hageman [EMAIL PROTECTED] wrote:
On Wed, 19 Feb 2003, Brian Paul wrote:
Felix Kühling wrote:
Hello list,
D. Hageman and I have been bouncing a design document for the new
configuration infrastructure back and forth in private mail
/\ \_\ \_\ \__U___just not everything
[EMAIL PROTECTED]o__/ \___/ \___/at the same time!
DRI Configuration Infrastructure (Draft)
Felix Kühling [EMAIL PROTECTED], D. Hageman [EMAIL PROTECTED]
19 February 2003
1. Introduction
---
Many proprietary OpenGL
On Thu, 13 Feb 2003 00:49:36 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Excellent.
Can someone commit this? Does this fix *all* the problems? I don't know if
it would.
It fixes all SW TCL related vertex problems I observed. I think it does
not fix the texture state problem we
On Thu, 13 Feb 2003 15:29:44 +0100 (CET)
Martin Spott [EMAIL PROTECTED] wrote:
Can someone commit this? Does this fix *all* the problems? I don't know if
it would.
It probably fixes SW TCL bugs - as Felix states - but it does not touch the
HW TCL related problems with the radeon
On Thu, 13 Feb 2003 10:35:53 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
On Thu, 13 Feb 2003 00:49:36 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Excellent.
Can someone commit this? Does this fix *all* the problems? I don't know if
it would.
It fixes all SW TCL related
On Mon, 10 Feb 2003 15:43:49 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
The document is not 100% complete. A few sections, such as the
replacement policy, need more discussion before they can be completed.
I have also included an issues
Hi,
I tracked down a problem that caused the rpm and speed meters in Torcs
to be invisible if TCL was disabled. I think it boils down to a missing
radeonEmitState. It is possible that radeonEmitState is not called after
ValidateState has updated the state atoms and before the first primitive
with
On Sun, 09 Feb 2003 07:32:38 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
I tracked down a problem that caused the rpm and speed meters in Torcs
to be invisible if TCL was disabled. I think it boils down to a missing
radeonEmitState. It is possible
On Sun, 09 Feb 2003 09:53:55 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
On Sun, 09 Feb 2003 07:32:38 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
I tracked down a problem that caused the rpm and speed meters in Torcs
Hi,
There were some seemingly random lockups with with my Radeon 7500. Now I
found out that they are actually reproducable. Run for instance the
gflux xscreensaver hack repeatedly. Short after starting it the 32nd
time X locks up. RADEON_DEBUG_DMA=1 output indicates that this is
another DMA
Found it. DRIVER_RELEASE in radeon.h has to call radeon_reclaim_buffers
as the drm_drv.h template seems to expect DRIVER_RELEASE to handle this.
DRIVER_RELEASE in i810.h does this too. The (1 line) patch is attached.
Felix
On Sat, 8 Feb 2003 17:49:15 +0100
Felix Kühling [EMAIL PROTECTED] wrote
Hi,
while I was trying to understand the DMA buffer allocation of the radeon
driver a few months ago I added an assertion at the end of
radeonAllocDmaRegion:
assert (rmesa-dma.current.ptr = rmesa-dma.current.end);
It fails if someone tries to allocate more DMA buffer space than one DMA
I attached a patch that fixes the problem. It introduces a new
TCL_FALLBACK if there are too many vertices to fit into one DMA buffer.
Looks kind of hackish to me. Does anyone have a better idea? Comments?
Regards,
Felix
On Wed, 5 Feb 2003 12:04:45 +0100
Felix Kühling [EMAIL PROTECTED] wrote
On Thu, 06 Feb 2003 07:46:35 +1000
Chris Ison [EMAIL PROTECTED] wrote:
a couple of us QF codes are questioning this, looks like gcc
optimizations or gdb are interefering cause the way QF handles the
vertex array (with error checking), it's impossable for starters for it
send a NULL indices
On Wed, 05 Feb 2003 16:25:27 -0700
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
I attached a patch that fixes the problem. It introduces a new
TCL_FALLBACK if there are too many vertices to fit into one DMA buffer.
Looks kind of hackish to me. Does anyone have a better idea
On Wed, 5 Feb 2003 20:17:57 -0500 (EST)
Leif Delgass [EMAIL PROTECTED] wrote:
Hurrah! ... this fixes the vertex data corruption in the UT2003 opening
screen. There's still vertex problems in game (though not quite as much).
The remaining problems may be because of cube mapping (I'm testing
On Wed, 29 Jan 2003 03:00:00 +0100 (MET)
Peter Finderup Lund [EMAIL PROTECTED] wrote:
On Tue, 28 Jan 2003, Felix Kühling wrote:
prefetching looks odd to me. In the first transform loop in
_mesa_3dnow_transform_normalize_normals memory is prefetched which is
never read but only written
On Wed, 29 Jan 2003 07:59:30 -0700
Brian Paul [EMAIL PROTECTED] wrote:
Since these functions are globally exported, it might be worth it to
write a quick test that calls the various
_transform_normalize_normals functions to make sure that they all
produces the same (or close enough)
On Tue, 28 Jan 2003 15:05:30 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
I'll see if I can clean this up a bit. On the mesa-4-0-4 branch this
code is disabled anyway, so there is not really a hurry to apply my
stupid little patch. About this reading backward thing, where is that
Hi,
I recently discovered some problem with normal vectors in the gflux hack
on my Duron, Radeon 7500 with and without TCL, even with
RADEON_NO_RAST=1. LIBGL_ALWAYS_INDIRECT works correctly, though.
A workaround is MESA_NO_3DNOW=1. Another way is to normalize the normals
in gflux and change
On Tue, 28 Jan 2003 13:10:41 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
It seems I like answering my own mails ;-)
I fixed this problem but it is probably not optimal. A simple patch is
attached. It seems that this error was introduced by an atempt to
optimize
Hello list,
We've been discussing general issues regarding the new DRI configuration
system recently on IRC. The most user-visible issue is the configuration
file format (until there is a GUI tool ;-).
In any case we need a more structured (nested) format than win.ini since
we want to be able to
Hello,
I could reproduce your X lockups with my Radeon 7500 by disabling TCL
(RADEON_TCL_FORCE_DISABLE=1) which is as close as I can get to your
Radeon VE. I don't use the dri_resume patch. From your telling that it
helped to kill the offending GL app it sounds like the GL app gets stuck
On Sun, 26 Jan 2003 15:37:03 +
[EMAIL PROTECTED] wrote:
Could you reproduce a lockup with a GL app running in a remote debugger
session. When the system is locked up you press Ctrl+C in the debugger,
get backtrace with the bt command and send it to the list.
I tried to do this from a
On Fri, 13 Dec 2002 16:58:35 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
One more thing, do you think I should submit my patch to XFree86 as
well? Could be a good oportunity to become a member there and get access
to NDA docs. Are radeon specs available there? I
On Tue, 10 Dec 2002 10:37:07 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Charl P. Botha wrote:
On Mon, Dec 09, 2002 at 10:30:35PM +, Keith Whitwell wrote:
Charl P. Botha wrote:
On Mon, Dec 09, 2002 at 09:45:12PM +, Keith Whitwell wrote:
There's a fix for this in recent cvs:
On 07 Dec 2002 02:07:03 +0100
Michel Dänzer [EMAIL PROTECTED] wrote:
On Die, 2002-12-03 at 23:17, Felix Kühling wrote:
I just tried glaxium myself. And it freezes the Xserver here too.
However, I don't have to move the window :-/ it always freezes about 3
seconds after I enter the game
On 07 Dec 2002 02:07:03 +0100
Michel Dänzer [EMAIL PROTECTED] wrote:
On Die, 2002-12-03 at 23:17, Felix Kühling wrote:
I just tried glaxium myself. And it freezes the Xserver here too.
However, I don't have to move the window :-/ it always freezes about 3
seconds after I enter the game
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 Mon, 2 Dec 2002 18:43:25 -0800
Allen Akin [EMAIL PROTECTED] wrote:
On Mon, Dec 02, 2002 at 02:00:49PM +0100, Felix Kühling wrote:
| So if we agree on this, I would make this
| controlled by an environment variable. ...
The intent of the spec is that drivers
On Tue, 3 Dec 2002 20:15:29 +0100
Dieter Nützel [EMAIL PROTECTED] wrote:
Am Dienstag, 3. Dezember 2002 19:12 schrieb Felix Kühling:
Hi all,
could I remind you of the original subject of this thread? ;-) It sounds
like the discussions about a new configuration tool could go
On Tue, 3 Dec 2002 11:44:28 -0700
Nicholas Leippe [EMAIL PROTECTED] wrote:
Just a quick question--what game are those screen shots from?
torcs.sourceforge.net
Cheers,
Felix
__\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
On 29 Nov 2002 09:37:15 -0800
Bret Towe [EMAIL PROTECTED] wrote:
last night i installed glaxium (0.5) for the first time
and was playing it runs great
however when i move the window it freezes x within a minute
sometimes even less
but as long as i dont move the window it plays fine
this
On Mon, 2 Dec 2002 00:59:34 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
Hi,
I reported a DMA buffer allocation problem earlier today with glean. It
terminated with Error: Could not get dma buffer ... exiting. I looked
into it a bit more now. I made a glean run with RADEON_DEBUG_DMA
On Mon, 02 Dec 2002 10:47:54 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
I made two small modifications to the radeon driver to make OpenGL look
much nicer with 16bpp. The first thing is to enable dithering, the
second is to use 32bpp textures even in 16bpp
Hello,
First of all, thanks for all the comments I received in this thread.
During the last few days I was also inspired to start more systematic
reading of the MESA and Radeon driver source codes. In these 5 days I
learned more than in 5 months before!
As to the subject, there are three main
Hi,
I made two small modifications to the radeon driver to make OpenGL look
much nicer with 16bpp. The first thing is to enable dithering, the
second is to use 32bpp textures even in 16bpp mode, if the application
requests them. A patch is attached.
Maybe the texture color depth should be
On Sun, 01 Dec 2002 14:57:45 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
[snip]
Index: radeon_state_init.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_state_init.c,v
retrieving
On Sun, 1 Dec 2002 18:43:10 +0300
Nick Kurshev [EMAIL PROTECTED] wrote:
[snip]
(gdb) info all-registers
eax0x10 16
ecx0x8289420136877088
edx0x8072a70134687344
ebx0x827c984136825220
esp0xbfffed98
On Sun, 1 Dec 2002 17:01:44 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
[snip]
I couldn't run a complete glean test. It failed with Error: Could not
get dma buffer... exiting. The strange thing is, this only happened if
the glean standard output went to an rxvt in the background. When I
On Sun, 1 Dec 2002 14:56:58 -0500 (EST)
Adam K Kirchhoff [EMAIL PROTECTED] wrote:
Hello all,
I recently upraded from an SMP VIA PIII motherboard to a UP Intel
I845 P4 motherboard. So far, things have gone pretty smoothly (I've
needed to upgrade to 2.4.20 to support the new ICH4
Hi,
I reported a DMA buffer allocation problem earlier today with glean. It
terminated with Error: Could not get dma buffer ... exiting. I looked
into it a bit more now. I made a glean run with RADEON_DEBUG_DMA and
wrote a small TCL script to analyse the output. It revealed a leak of
DMA buffers.
On 30 Nov 2002 13:53:40 +0100
Michel Dänzer [EMAIL PROTECTED] wrote:
On Sam, 2002-11-30 at 09:11, Bret Towe wrote:
x just died on me for some reason and i noticed this in xfree's log
i dont know if this was the cause of the death (it just droped back to
console btw) since there isnt a
On Fri, 29 Nov 2002 07:55:52 -0700
Brian Paul [EMAIL PROTECTED] wrote:
[snip]
Implementing a true threaded pipeline could be very compilicated. State
changes are the big issue. If you stall/flush the pipeline for every
state change you wouldn't gain anything. The alternative is to associate
On Sat, 30 Nov 2002 16:24:59 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
[snip]
I found many state changing callbacks in dd.h which don't seem to be
used. Are they left-overs from earlier Mesa versions or did my grep miss
something?
Which ones?
Ok, I got
On Sat, 30 Nov 2002 17:20:04 +0100
Felix Kühling [EMAIL PROTECTED] wrote:
On Fri, 29 Nov 2002 07:55:52 -0700
Brian Paul [EMAIL PROTECTED] wrote:
[snip]
Implementing a true threaded pipeline could be very compilicated. State
changes are the big issue. If you stall/flush the pipeline
601 - 700 of 815 matches
Mail list logo
