Re: [Dri-devel] radeon bugs
David Dawes wrote: On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote: On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote: There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David, I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4, and the DRI developers aren't tracking Mesa 4.0.x anymore. We are at Mesa 5.0.2. Doesn't the DRI project maintain a Mesa 5.0.x-based stable branch of some sort? David, The hardware drivers are now being maintained in the Mesa tree. Mesa does have a set of stable branches but the only one containing the DRI drivers is too recent for your purposes - Mesa 6.0. This is a good time to remind people/establish the principle that driver bug fixes should be propogated to the mesa-6_0_branch of the Mesa repository. Brian's always done a good job of making sure core mesa fixes get copied over, but it shouldn't come down to him alone. In particular, the recent TCL lighting fixes for the radeon r200 drivers should get pushed down into Mesa 6.0. Keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Re: [XFree86] Re: DRI weirdnesses for RADEON 9200
I was pretty sure that the snapshots did staticly link with libexpat.a. I remember there being some discussion about this. Once XFree86 4.4.0 hits the streets this particular problem will be moot. AFAIK, XFree86 4.4.0 will include libexpat. However, I still think that the default should be to log the error messages when the _dri.so will not load or is missing required symbols. I'd be happy to see this happen asap. Keith ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [Dri-devel] Deadlock with radeon DRI
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 have filed an XFree86 bug report on this. I could not find a DRI specific bug reporting mechanism other than the dri-devel list. This list is good. Can you put together a patch to correct the behaviour? Keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Deadlock with radeon DRI
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 problem.
The symptom of the problem is the following message from the drm
radeon kernel driver:
[drm:radeon_lock_take] *ERROR* x holds heavyweight lock
where x is a context id. I've tracked the sequence of events down to
the following:
DRIFinishScreenInit is called during the radeon driver initialization,
inside DRIFinishScreenInit is the following code snippet:
/* Now that we have created the X server's context, we can grab the
* hardware lock for the X server.
*/
DRILock(pScreen, 0);
pDRIPriv-grabbedDRILock = TRUE;
Slightly later on RADEONAdjustFrame is called and it does the following:
#ifdef XF86DRI
if (info-CPStarted) DRILock(pScrn-pScreen, 0);
#endif
Its this DRILock which is causing the *ERROR* x holds heavyweight
lock message. The reason is both DRIFinishScreenInit and
RADEONAdjustFrame are executing in the server and using the servers
DRI lock. DRIFinishScreenInit never unlocks, it sets the
grabbedDRILock flag, big deal, no one ever references this flag. When
RADEONAdjustFrame calls DRILock its already locked because
DRIFinishScreenInit locked and never unlocked. The dri kernel driver
on the second lock call then suspends the X server process
(DRM(lock_take) returns zero to DRM(lock) because the context holding
the lock and context requesting the lock are the same, this then
causes DRM(lock) to put the X server on the lock wait queue). Putting
the X server on the wait queue waiting for the lock to be released
then deadlocks the X server because its the process holding the lock
on its context.
Questions:
The whole crux of the problem seems to me the taking and holding of
the lock in DRIFinishScreenInit. Why is this being done?
It is done because the X server expects to be holding the lock whenever it is
between the Wakeup Block handlers. The odd man out in this case is when the
server first starts up, it won't have aquired the lock coming in through the
Wakeup handler. So, it gets aquired at this point.
The rest of the DRI initialization code needs to be holding the lock, so we
have to grab it somewhere.
The problem seems to be that RADEONAdjustFrame() is designed to be called from
cursor handling routines that are executed outside the Wakeup/Block handlers
(perhaps this came in with SilkenMouse?) but is being called during
initialization after the point the lock is grabbed.
I haven't deeply investigated this but two solutions spring to mind:
- Hack: Move the call to RADEONAdjustFrame() during initialization to before
the lock is grabbed.
- Better: Replace the call to RADEONAdjustFrame() during initialization with
something like:
if (info-FBDev) {
fbdevHWAdjustFrame(scrnIndex, x, y, flags);
} else {
RADEONDoAdjustFrame(pScrn, x, y, FALSE);
}
which is basically what RADEONAdjustFrame() wraps.
Keith
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Deadlock with radeon DRI
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 architecture specific about the problem. The symptom of the problem is the following message from the drm radeon kernel driver: [drm:radeon_lock_take] *ERROR* x holds heavyweight lock where x is a context id. I've tracked the sequence of events down to the following: DRIFinishScreenInit is called during the radeon driver initialization, inside DRIFinishScreenInit is the following code snippet: /* Now that we have created the X server's context, we can grab the * hardware lock for the X server. */ DRILock(pScreen, 0); pDRIPriv-grabbedDRILock = TRUE; Slightly later on RADEONAdjustFrame is called and it does the following: #ifdef XF86DRI if (info-CPStarted) DRILock(pScrn-pScreen, 0); #endif Its this DRILock which is causing the *ERROR* x holds heavyweight lock message. The reason is both DRIFinishScreenInit and RADEONAdjustFrame are executing in the server and using the servers DRI lock. DRIFinishScreenInit never unlocks, it sets the grabbedDRILock flag, big deal, no one ever references this flag. When RADEONAdjustFrame calls DRILock its already locked because DRIFinishScreenInit locked and never unlocked. The dri kernel driver on the second lock call then suspends the X server process (DRM(lock_take) returns zero to DRM(lock) because the context holding the lock and context requesting the lock are the same, this then causes DRM(lock) to put the X server on the lock wait queue). Putting the X server on the wait queue waiting for the lock to be released then deadlocks the X server because its the process holding the lock on its context. Questions: The whole crux of the problem seems to me the taking and holding of the lock in DRIFinishScreenInit. Why is this being done? It is done because the X server expects to be holding the lock whenever it is between the Wakeup Block handlers. The odd man out in this case is when the server first starts up, it won't have aquired the lock coming in through the Wakeup handler. So, it gets aquired at this point. The rest of the DRI initialization code needs to be holding the lock, so we have to grab it somewhere. The problem seems to be that RADEONAdjustFrame() is designed to be called from cursor handling routines that are executed outside the Wakeup/Block handlers (perhaps this came in with SilkenMouse?) but is being called during initialization after the point the lock is grabbed. Actually, looking more closely at RADEONAdjustFrame(), I would guess that the test of (info-CPStarted) is designed to avoid precisely this problem, right? So I wonder why that's not working for you... Keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] DRI problem
Thomas Winischhofer wrote: Keith Whitwell wrote: Thomas Winischhofer wrote: Keith Whitwell wrote: Unless someone can tell me I'm wrong, the SiS driver hasn't been maintained in a long time. It sounds like it's quite broken should be turned off. You are *not* wrong: The SiS DRI driver hasn't been maintained for a while. But your conclusion is wrong: It works (in Mesa 3 implementation) quite OK. ID's games work like a charm. OK, that's news to me. It shouldn't be too hard to port it -- a reasonable project for someone interested in getting involved on the 3d side. I think so, too - but I am far too busy with the 2D driver (which keeps me from sleeping more than 5 hours per night since back in 2001...) Sorry Thomas - I wasn't trying to imply that you should do it... Keith ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] DRI problem
Andrew Barr wrote: I am having a problem using DRI on my SiS 630 based board. Everything seems OK...the X log says that DRI is enabled, the libGL.so.1.2 library supports DRI (checked by strings libGL.so.1.2 | grep DRI as per the DRI debug page: http://gatos.sourceforge.net/dri-debug.php), and the modified sisfb, X driver, and DRI driver are in place from the Linux SiS VGA chipsets page (I am using XFree 4.2.1 on Mandrake 9), but every program, from Tuxracer, to glxgears, and even glxinfo, fall back on indirect rendering. I have gone through the steps available at this web site and all indications are that DRI should work. I have used to the page indicated above, and, again, even though it is geared towards ATI users it does include DRI info and it still does not work. If anyone has any additional steps I could take or just some wisdom in general it would be much appreciated. I have pretty much reached the end of the line as far as searching out my problem on Google...tips start to get redundant. Thanks in advance to anyone who can help!!! Unless someone can tell me I'm wrong, the SiS driver hasn't been maintained in a long time. It sounds like it's quite broken should be turned off. Keith ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [Bug 25] New: radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext:Assertion `vb.context == ctx' failed.
[EMAIL PROTECTED] wrote: Further details about my current configuration: Linux: Debian GNU/Linux unstable CPU: Athlon 1.3GHz RAM: 1024M XFree86: 4.3.0, built from source Video Card: ATI All-In-Wonder Radeon, with updated drivers from GATOS (experimental 8) OpenGL appears to work almost entirely flawlessly. However, whenever I run Blender, and click the render button, blender crashes with this error message: = radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext: Assertion `vb.context == ctx' failed. = This crash happens if I've loaded a scene and click render, if I've created a scene and click render, or if I do nothing, and just click render. The searching I've done online seems to point to this being an issue in XFree86, as opposed to the GATOS drivers, so is being reported here. Most other things seem to be working well (quake2, gltron, etc). Any feedback on this would be most appreciated. This is reported as being fixed in current DRI cvs. Keith ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] [Bug 25] New: radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext:Assertion `vb.context == ctx' failed.
Michel Dänzer wrote: On Sam, 2003-03-22 at 17:18, Keith Whitwell wrote: [EMAIL PROTECTED] wrote: Further details about my current configuration: Linux: Debian GNU/Linux unstable CPU: Athlon 1.3GHz RAM: 1024M XFree86: 4.3.0, built from source Video Card: ATI All-In-Wonder Radeon, with updated drivers from GATOS (experimental 8) OpenGL appears to work almost entirely flawlessly. However, whenever I run Blender, and click the render button, blender crashes with this error message: = radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext: Assertion `vb.context == ctx' failed. = This crash happens if I've loaded a scene and click render, if I've created a scene and click render, or if I do nothing, and just click render. The searching I've done online seems to point to this being an issue in XFree86, as opposed to the GATOS drivers, so is being reported here. Most other things seem to be working well (quake2, gltron, etc). Any feedback on this would be most appreciated. This is reported as being fixed in current DRI cvs. I wonder if the bug submitter reads this list though - people will have to get used to following up to bugs in bugzilla. Unless someone beats me to it, I'll follow up to this bug with a patch for him to try and other information. Go ahead Michel. Keith ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [Dri-devel] Re: XFree86 bugzilla available
José Fonseca wrote: No DRI developer expressed his interest or opposition, probably because there isn't opposition, or simply no interest. In either case I see no reasons why not proceed, so I'll open a bug to address this. I'll ask that [EMAIL PROTECTED] (the same addressed used on SF BT system) is set as the default owner for DRI bugs. Also, what's the general mailing list one can subscribe to receive notifications everytime a bug is open? Sorry... I think it's a good idea as proposed. Keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] radeon dri xserver recycle lockup
In fact the lockup comes down to this one line:
--- radeon_driver.c28 Oct 2002 02:21:14 -1.44
+++ radeon_driver.c29 Oct 2002 13:49:25 -1.45
@@ -4639,6 +4639,7 @@
save-cap0_trig_cntl = 0;
save-cap1_trig_cntl = 0;
save-bus_cntl = info-BusCntl;
+save-gen_int_cntl = info-gen_int_cntl;
/*
* If bursts are enabled, turn on discards
* Radeon doesn't have write bursts
Michel, what are the consequences of removing this?
Hmm. Things are slightly compilcated by the fact that this code has been
reworked since this change was made. To get rid of the lockup on the dri
trunk I have to use the attached patch. It's a little heavy handed...
Anyone have any better ideas? Otherwise I'm going to commit this here as it
at least it resolves the lockup.
Keith
Index: radeon_dri.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c,v
retrieving revision 1.44
diff -u -r1.44 radeon_dri.c
--- radeon_dri.c6 Feb 2003 19:13:40 - 1.44
+++ radeon_dri.c12 Mar 2003 10:50:20 -
@@ -1148,7 +1148,7 @@
info-irq = 0;
} else {
unsigned char *RADEONMMIO = info-MMIO;
- info-ModeReg.gen_int_cntl = INREG( RADEON_GEN_INT_CNTL );
+ info-ModeReg.gen_int_cntl = 0; /* INREG( RADEON_GEN_INT_CNTL ); */
}
}
Index: radeon_driver.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.56
diff -u -r1.56 radeon_driver.c
--- radeon_driver.c 25 Jan 2003 22:25:44 - 1.56
+++ radeon_driver.c 12 Mar 2003 10:50:21 -
@@ -4384,7 +4384,7 @@
save-subpic_cntl= INREG(RADEON_SUBPIC_CNTL);
save-viph_control = INREG(RADEON_VIPH_CONTROL);
save-i2c_cntl_1 = INREG(RADEON_I2C_CNTL_1);
-save-gen_int_cntl = INREG(RADEON_GEN_INT_CNTL);
+save-gen_int_cntl = 0; /* INREG(RADEON_GEN_INT_CNTL); */
save-cap0_trig_cntl = INREG(RADEON_CAP0_TRIG_CNTL);
save-cap1_trig_cntl = INREG(RADEON_CAP1_TRIG_CNTL);
save-bus_cntl = INREG(RADEON_BUS_CNTL);
@@ -4400,7 +4400,7 @@
/* Save register for vertical blank interrupts */
if (info-irq) {
- save-gen_int_cntl = INREG(RADEON_GEN_INT_CNTL);
+ save-gen_int_cntl = 0; /* INREG(RADEON_GEN_INT_CNTL); */
}
/* Save registers for page flipping */
[XFree86] Re: [Dri-devel] radeon dri xserver recycle lockup
Michel Dänzer wrote: On Mit, 2003-03-12 at 11:51, Keith Whitwell wrote: In fact the lockup comes down to this one line: --- radeon_driver.c28 Oct 2002 02:21:14 -1.44 +++ radeon_driver.c29 Oct 2002 13:49:25 -1.45 @@ -4639,6 +4639,7 @@ save-cap0_trig_cntl = 0; save-cap1_trig_cntl = 0; save-bus_cntl = info-BusCntl; +save-gen_int_cntl = info-gen_int_cntl; /* * If bursts are enabled, turn on discards * Radeon doesn't have write bursts Michel, what are the consequences of removing this? Hmm. Things are slightly compilcated by the fact that this code has been reworked since this change was made. To get rid of the lockup on the dri trunk I have to use the attached patch. It's a little heavy handed... It basically disables interrupts AFAICS. No - they still seem to work, which makes sense as they are turned on in the drm module (which also writes to RADEON_GEN_INT_CONTROL). Keith ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [Dri-devel] remaining (reproducible) problems with 4.2.99.902on Radeon M7
3. A good old segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1026 (LWP 712)]
0x404dd042 in _swrast_InvalidateState ()
from /usr/X11R6/lib/modules/dri/radeon_dri.so
(gdb) bt
#0 0x404dd042 in _swrast_InvalidateState ()
from /usr/X11R6/lib/modules/dri/radeon_dri.so
#1 0x4058b6ac in radeonInvalidateState ()
from /usr/X11R6/lib/modules/dri/radeon_dri.so
#2 0x404a6edd in _mesa_update_state ()
from /usr/X11R6/lib/modules/dri/radeon_dri.so
#3 0x4045e0e0 in _mesa_Clear () from /usr/X11R6/lib/modules/dri/radeon_dri.so
#4 0x401132f5 in _ts_Clear () from /usr/X11R6/lib/libGL.so.1
#5 0x08049275 in draw_loop ()
#6 0x0804995a in thread_function ()
#7 0x40337fa5 in pthread_start_thread () from /lib/libpthread.so.0
#8 0x40337fed in pthread_start_thread_event () from /lib/libpthread.so.0
This occurs because you have modified the X event loop to destroy a context
that *IS STILL IN USE* in another thread. GL doesn't provide any guarantees
about what will happen if you try to do this...
One way to achieve something like what you want would be to make ExitFlag an
array, and destroy the context at the end of draw_loop. I've attached
something that does this.
This doesn't solve all of your problems, though - I'm still looking at them.
Keith
/* $Id: glthreads.c,v 1.1 2000/07/20 20:12:17 brianp Exp $ */
/* modified by [EMAIL PROTECTED] to destroy current window and context when
* key pressed...
*/
/*
* Copyright (C) 2000 Brian Paul All Rights Reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the Software),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included
* in all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
* OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
* AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
/*
* This program tests GLX thread safety.
* Command line options:
* -n num threads Number of threads to create (default is 2)
* -display display name Specify X display (default is :0.0)
*
* Brian Paul 20 July 2000
*/
#if defined(PTHREADS) /* defined by Mesa on Linux and other platforms */
#include GL/gl.h
#include GL/glx.h
#include stdio.h
#include stdlib.h
#include unistd.h
#include pthread.h
/*
* Each window/thread/context:
*/
struct winthread {
Display *Dpy;
int Index;
pthread_t Thread;
Window Win;
GLXContext Context;
float Angle;
int WinWidth, WinHeight;
GLboolean NewSize;
GLboolean ExitFlag;
};
#define MAX_WINTHREADS 100
static struct winthread WinThreads[MAX_WINTHREADS];
static int NumWinThreads = 0;
static void
Error(const char *msg)
{
fprintf(stderr, Error: %s\n, msg);
exit(1);
}
/* draw a colored cube */
static void
draw_object(void)
{
glPushMatrix();
glScalef(0.75, 0.75, 0.75);
glColor3f(1, 0, 0);
glBegin(GL_POLYGON);
glVertex3f(1, -1, -1);
glVertex3f(1, 1, -1);
glVertex3f(1, 1, 1);
glVertex3f(1, -1, 1);
glEnd();
glColor3f(0, 1, 1);
glBegin(GL_POLYGON);
glVertex3f(-1, -1, -1);
glVertex3f(-1, 1, -1);
glVertex3f(-1, 1, 1);
glVertex3f(-1, -1, 1);
glEnd();
glColor3f(0, 1, 0);
glBegin(GL_POLYGON);
glVertex3f(-1, 1, -1);
glVertex3f( 1, 1, -1);
glVertex3f( 1, 1, 1);
glVertex3f(-1, 1, 1);
glEnd();
glColor3f(1, 0, 1);
glBegin(GL_POLYGON);
glVertex3f(-1, -1, -1);
glVertex3f( 1, -1, -1);
glVertex3f( 1, -1, 1);
glVertex3f(-1, -1, 1);
glEnd();
glColor3f(0, 0, 1);
glBegin(GL_POLYGON);
glVertex3f(-1, -1, 1);
glVertex3f( 1, -1, 1);
glVertex3f( 1, 1, 1);
glVertex3f(-1, 1, 1);
glEnd();
glColor3f(1, 1, 0);
glBegin(GL_POLYGON);
glVertex3f(-1, -1, -1);
glVertex3f( 1, -1, -1);
glVertex3f( 1, 1, -1);
glVertex3f(-1, 1, -1);
glEnd();
glPopMatrix();
}
/* signal resize of given window */
static void
resize(struct winthread *wt, int w, int h)
{
wt-NewSize = GL_TRUE;
wt-WinWidth = w;
wt-WinHeight = h;
}
/*
* We have an instance of this for each thread.
*/
static void
draw_loop(struct winthread *wt)
{
while (!wt-ExitFlag) {
glXMakeCurrent(wt-Dpy, wt-Win, wt-Context);
glEnable(GL_DEPTH_TEST);
if (wt-NewSize) {
GLfloat w =
Re: [Dri-devel] Re: [XFree86] [XFree86(TM) Bug Report] thread bugin xc/lib/GL/glx/glxcmd.c and glxext.c
Michel Dänzer wrote: [ please move this thread to the appropriate development list(s) ] On Fre, 2003-01-17 at 16:03, Alexis Vartanian wrote: problem : GL application hangs at starting (quake3 and a threaded) when running a multithread application, any call to _XRead should be done after a XLockDisplay is called. If you don't do that, a call to _XRead may make a call to _XWaitForReadable that calls XUnlockDisplay then XLockDisplay then the application freezes in the next XLockDisplay this is not the case in : glxext.c:387 and glxcmd.c:1439 the correction should be fairly easy, moving the XUnlockDisplay done earlier at the end of the function and anywhere in the path where the function exits I can provide a patch if wanted Please do. Michel, do you have a patch for this. I think this problem has come up in a separate instance with multithreaded applications -- it would be good to get it resolved. Keith ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[Xpert]Re: [Dri-devel] Savage and nVidia DRI drivers
Count me in as much as I can help. I can make the hardware sing but I know zilch about the Mesa end of things. I'm also interested in Voodoo2 since its for many people the best video card you can shove in old hppa boxes and in sis 6326 (because its a good simplicity test) At one point there was a shadowfb based 2d driver for the voodoo cards -- it would be interesting an interesting approach to add a dri layer to that driver, if it still exists. Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Savage and nVidia DRI drivers
Alan Cox wrote: On Thu, 2002-10-31 at 15:58, José Fonseca wrote: I don't know much about SIS 6326. I know that there is some deprecated (it hasn't been updated for the architectural changes) support for SIS 630 chips on the CVS. 6326 is much older than 630 and 315 etc. Its in the PIO with very small fifo category of devices. I've got the 3Dfx docs, and also some info on the bugs (you have to verify the stream as things like misordered triangle verticies kill the chip) On voodoo-1, even vertices that aren't snapped to 1/16th(?) subpixel coords will crash it... Hmmm, you can't do fp in the kernel, right? Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]512x512 OpenGL Texture for ATI 7500 Mobility?
Ti Leggett wrote: There seems to be a 512x512 OpenGL texture size limit for ATI 7500 Mobility. There's a game I'm helping test and it uses textures over 1024x1024 and they work on a regular ATI 7500 but don't on a 7500 Mobility. 512x512 textures do work though. Any ideas why this is? It's not a hardware limitation because the same game runs fine @ 1024x1024 textures under windows. Thanks! The maximum texture size is scaled down according to how much memory you have. There are games out there (quake 2, iirc) that don't behave correctly without this. It may be a behaviour that's outlived it's usefulness however -- it's not required by the GL spec at all. Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Dri-devel] Re: [Xpert]512x512 OpenGL Texture for ATI 7500 Mobility?
Brian Paul wrote: Keith Whitwell wrote: Ti Leggett wrote: There seems to be a 512x512 OpenGL texture size limit for ATI 7500 Mobility. There's a game I'm helping test and it uses textures over 1024x1024 and they work on a regular ATI 7500 but don't on a 7500 Mobility. 512x512 textures do work though. Any ideas why this is? It's not a hardware limitation because the same game runs fine @ 1024x1024 textures under windows. Thanks! The maximum texture size is scaled down according to how much memory you have. There are games out there (quake 2, iirc) that don't behave correctly without this. It may be a behaviour that's outlived it's usefulness however -- it's not required by the GL spec at all. I'm not sure I understand. We should advertise GL_MAX_TEXTURE_SIZE such that N textures of that size can be accomodated (where N = num texture units). OK, That's what we do. I didn't realize it was a requirement, however, I just did it to make q2 work properly many years ago. The windows driver probably is using agp texturing to fit the larger textures in, which we should do also. Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]PATCH: X-Video support for Radeon 8500
Keith Packard wrote: Around 17 o'clock on Jul 1, James Ralston wrote: So, it would appear that 3D support for the Radeon 64 DDR and the Radeon Mobility M6 LY (and I suspect all Radeons) was accidentally broken in CVS sometime on or before 2002-06-23. It's been broken for me on my M6 LY ever since Mesa 4 hit XFree86 CVS shortly after 4.2. I use the DRI tcl-0-0 branch on my 7500, but that wasn't working on my M6 when I last tried it a month or so ago. It's hard to do testing for the mobility cards without access to one... However, I've found a couple of obvious gotcha's in the recent code that can be cleared out -- we are still emitting some tcl state even on mobility cards which would certainly be causing some problems. Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Weird scan-rate related crash in Radeon driver
David D. Hagood wrote: I've come across a weird problem in the Radeon drivers in 4.2 - depending upon the horizontal scan rates I specify for my monitor, I can cause a divide by zero within the Radeon init code. You might be better off posting this problem on the Xpert (XFree86) mailing list. Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon 8500 kernel module
James H. Cloos Jr. wrote: Fabrice == Fabrice Bellet [EMAIL PROTECTED] writes: the FireGL driver does not enable bus mastering on the graphics card, but this is essential. So you have to do before starting the Xserver with setpci by setting bit 2 of the command register- Fabrice Wow it works, and it's damn fast! Fabrice glxgears gives these results : Fabrice 11305 frames in 5.0 seconds = 2261.000 FPS Fabrice 14153 frames in 5.0 seconds = 2830.600 FPS Fabrice 14106 frames in 5.0 seconds = 2821.200 FPS Fabrice 14142 frames in 5.0 seconds = 2828.400 FPS Fabrice 13498 frames in 5.0 seconds = 2699.600 FPS Fabrice 2121 frames in 5.0 seconds = 424.200 FPS Fabrice 2119 frames in 5.0 seconds = 423.800 FPS Fabrice The last two values are obtained in full screen 1024x768. That is a significant improvement over the 7500 M7 LW which gives: [default size] 4293 frames in 5.0 seconds = 858.600 FPS 4626 frames in 5.0 seconds = 925.200 FPS 4723 frames in 5.0 seconds = 944.600 FPS 4703 frames in 5.0 seconds = 940.600 FPS 4722 frames in 5.0 seconds = 944.400 FPS 3048 frames in 5.0 seconds = 609.600 FPS The tcl driver on dri.sf.net gives me 2200 FPS on a 7500 if I turn on page flipping. Did I meantion gears wasn't a good benchmark? Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]i810 + KDE display corruption
Paul Matthias Diderichsen wrote: Hi, [EMAIL PROTECTED] wrote: 3. i810 + KDE display corruption (Dirk =?ISO-8859-1?Q?St=F6ffler?=) A year ago, I had the severe version of the problem you describe. I was able to (almost - once in a while there are a few stribes) cure it by upgrading the bios of my IBM netvista 866 MHz P3. I'm afraid I can't help you with an URL to the bios-upgrade, but I remember that I found it somewhere on the IBM's site. Probably this will only help you, if you've got an IBM netvista, but otherwise you may add the pointer to your (already) quite impressive list. Kind regards, See also www.ekf.de/c/ccpu/cc5/firmware/wmi810.html I received mail from these guys a while ago but promptly forgot about it. I'm integrating their code now. Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: linux-drm-4.2.0-kernelsource.tar.gz fixes for 2.5.X
José Fonseca wrote: Jens, On 2002.05.13 14:58 Jens Owen wrote: Jose, I recommend a full two way merge (DRI-kernel and kernel-DRI). The kernel-DRI changes can be submitted directly to our repository for testing. The DRI-kernel changes require a patch be submitted to the kernel team. If we need two patches (for 2.4 and 2.5) that's okay--but we should try to end up with a common driver source for both kernel versions in our repository, if at all possible. Posting these patches on the DRI site is for the purpose of getting some alpha testing exposure and code review before submitting to the kernel team. Once we have merged sources in both repositories, then David and Alan can pick up the latest from our repository. Getting these fixes out minimizes our need to create patches relative to all the verious places the kernel DRM drivers can be found. I agree entirely with you. Does this plan cover our needs, or am I overlooking something? Nop, but who will do this? (I can't volunteer as I have no more spare time until June.) I would be nice to know what is the current state of affairs? Is it like: - both 2.4.x 2.5.x linux kernel series have the XFree 4.1.0 DRMs (with changes by the linux kernel developers to match the rest of the kernel). - the XFree86 4.2.0 tree has DRM source for early 2.4.x series - for 2.4.18 changes are required, for which Mike made a patch - for 2.5.x likewise, for which Micah patched the radeon kernel only And what is necessary to do is: - adapt the DRI CVS kernel modules to build in at least three kernel versions, - make a patch against the latest 2.4.x and 2.5.x kernels Is this picture correct? José Fonseca I'll look at taking this on. Just got to get up to speed with it as I'm a bit behind on the issues. Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]libGLcore/DRI question
Mark Vojkovich wrote: Currently, for libXvMC, Intel and NVIDIA have static libraries that work essentially like libGLcore and is used in conjuction with libXvMC.a. I want to move to a libXvMC.so plus libXvMCcore.so type operation where libXvMC dlopens the appropriate core for the hardware being used. Does the DRI do this sort of thing? How do you know which core to load? It does if I understand the question. It gets the driver name from a DRI extension protocol request to the server - the ddx driver knows which module to load. The path to the driver.so is from a hardcoded default or overridden by an environment variable - however, I kindof believe it would have made more sense for the server to give an absolute path. Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
Vladimir Dergachev wrote: On Wed, 30 Jan 2002, Gareth Hughes wrote: Gareth, the current driver is broken. If someone wants to use video capture they _need_ both GATOS 2d driver and GATOS drm driver, period. What's so wrong about upgrading ? Guaranteed, someone will get a mismatch -- your changes may go back into the stock kernel, breaking DRI CVS or whatever, who knows. Forcing everyone to upgrade their kernel, 2D and 3D drivers to the right magic revision is a recipe for disaster, one that the kernel people have already kicked our arses over (rightly so). Also, I can make drm driver work nice with older 2d drivers - as soon as someone will show me a way to tell the version of the 2d driver that is accessing the drm driver. Sounds like it'll need a 2D driver upgrade :-) So what are you proposing ? Not to fix it ? We have a system where a driver is split in three components all of which have to agree on the hardware state. There is just so much you can do for backward compatibility. You can do less if you can't find one component version from another one. Do it the old way by default, and if you receive some new ioctl, do it the new way. As for Linus not wanting to accept it, 2.4 has dropped most nat filters except for ftp and most of them aren't back yet. So I don't buy this argument. Trust us. It's the right thing to do, whether Linus or anybody else says so. Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
Vladimir Dergachev wrote: On Wed, 30 Jan 2002, deek wrote: Vladimir Dergachev scribbled: __snipped_ I've implemented this (easier than software CCE) scheme. If you want to please try the latest ati.2 CVS code at http://gatos.sf.net - or just take a look at it. Basically I put in info-accel-Sync(pScrn) at entrance points into Xv driver. SetupImageVideo, StopVideo, SetPortAttribute, GetPortAttribute and PutVideo are all control calls, perfomance is not critical. PutImage should, arguably, take more time during image trasfer.. And if you are playing Quake and watching DVD at the same you are making problems for yourself anyway ;) (And the faster the card the less noticable any slowdown from extra Sync calls will be) I've checked this out. Seems that there is a buggaboo in the radeon implementation. I don't know if the same would apply for R128, seems that it might. GATOS Radeon driver has the proper handling of memory controller. Consequently, usual drm modules will not work - you need to use drm-kernel package available at http://gatos.sf.net/ Vladimir Dergachev Is there any reason the drivers can't be merged? Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossiblyradeonDMA functions
Vladimir Dergachev wrote: On Wed, 30 Jan 2002, Daryll Strauss wrote: On Wed, Jan 30, 2002 at 02:05:42PM -0500, Vladimir Dergachev wrote: Regardless of the way it is merged the driver major version will need to be bumped. GATOS drivers does this but only minor - as I did not want to upload a mesa radeon driver just because of the version change. I'm afraid I haven't been following this discussion closely enough, but I found this statement sort of odd, so I thought I'd comment. Version numbers for kernel interfaces are rather different than those for normal software packages. In normal software packages they are more of a vanity thing. A minor version number bump means small things changed, and a major one means hey we did big things. In kernel drivers they are really important as they describe the API between the kernel and the user space application. There are very strict rules about which version numbers are changed when. The major version of a driver should be incremented if and only if there are incompatible changes to the driver that prevent older versions from working. You obviously want to minimize these sorts of changes, so that you don't break compatability. For example, lets say we found a big security hole in an IOCTL. The first thing we'd try to do is rewrite the function so avoid the hole. Maybe even in a way that's really slow. As long as the interface remains the same that's fine. We might add a new interface that's fast again, but keep the old one around for backward compatability. If that's completely impossible then we remove the IOCTL and bump the major version number. If you add or change functionality, but the old drivers still work, then a minor version number should be bumped. Drivers will check for a matching major number and minor number that is greater than or equal to the one they need. So, again if we go back to that security problem. If we rewrote the old IOCTL to be slow but secure and added a new one that is safe and fast, the minor number would be bumped. If you just fix a bug or make some really small change that doesn't impact the interface, then you bump the third digit. Third digits are ignored by the software and are really just documentation. I completely agree with you.. but I did not give you details :)) What happens is that if you try to use older drm driver with GATOS 2d driver the GATOS driver will notice and complain. But if you use GATOS drm driver with older 4.2.0 2d driver you will get a lockup. The reason is that the changes involve programming Radeon's memory controller to place AGP aperture after the end of the framebuffer and not at the start of PCI space as it is done currently. Both 2d driver and drm driver have to agree on this - which is why a bump in major version is necessary. This will never be accepted by Linus, Alan or any of the kernel people. You need to find a way to make existing (distributed) clients work with the new kernel modules. Major number bumps are essentially illegal - we've promised not to do this. I don't know how to achieve your changes under that restriction... Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossiblyradeonDMA functions
Vladimir Dergachev wrote: On Wed, 30 Jan 2002, Daryll Strauss wrote: On Wed, Jan 30, 2002 at 03:15:53PM -0500, Vladimir Dergachev wrote: I completely agree with you.. but I did not give you details :)) What happens is that if you try to use older drm driver with GATOS 2d driver the GATOS driver will notice and complain. But if you use GATOS drm driver with older 4.2.0 2d driver you will get a lockup. The reason is that the changes involve programming Radeon's memory controller to place AGP aperture after the end of the framebuffer and not at the start of PCI space as it is done currently. Both 2d driver and drm driver have to agree on this - which is why a bump in major version is necessary. The reason I did not do it is that the mesa driver checks major version as well. Hence it will complain if it is bumped. Since I did not want to open a new CVS module just for changing version in mesa driver I decided to go the slightly broken way under assumption that few people with install GATOS drm-kernel but will forget to install GATOS 2d driver. Does this make sense ? Sure does, but it sounds like we could change the Mesa drivers to have the same behavior as the GATOS drivers. If they see version x.y they use the old offset for AGP and if they see x.y+1 they use the new one. This would be much better than bumping the major version number. I may be glossing over details, in fact I probably am, but putting some effort into this is probably required if we want to be good Linux citizens. That's a good idea.. Except that it wont' work. Mesa driver is distributed with XFree86 anyway, so when GATOS patch gets merged in everything will work ok. The problem is that I don't know how drm driver can check the version of 2d driver that attempts to initialize it - if you know how please let me know. Without this, first thing after we include mew drm driver into Linux kernel we'll have people downloading it and getting a lockup with 4.2.0 or earlier. It won't be included if it bumps the major number. You need to come up with a way to do this so that old clients *just work*, and new ones do something special to access new functionality. I'd also be wary of assuming that people have the same versions of 2d and 3d drivers installed. Keith ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
