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: [XFree86] [Bug 25] radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext:Assertion `vb.context == ctx' failed.
So, this is fixed in current DRI CVS trunk -- how should this be indicated/handled? Keith [EMAIL PROTECTED] wrote: [This e-mail has been automatically generated.] http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=25 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
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
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. 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.
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: [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
[XFree86] Re: [Dri-devel] Re: radeon dri xserver recycle lockup
Michel Dänzer wrote:
On Mit, 2003-03-12 at 12:29, Keith Whitwell wrote:
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).
But they stop working when you switch modes, don't they?
Does this patch (against the XFree86 trunk) help instead?
Index: programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c,v
retrieving revision 1.32
diff -p -u -r1.32 radeon_dri.c
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 2003/02/19 09:17:30 1.32
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 2003/03/12 13:08:30
@@ -1585,6 +1585,7 @@ void RADEONDRICloseScreen(ScreenPtr pScr
if (info->irq) {
drmCtlUninstHandler(info->drmFD);
info->irq = 0;
+ info->ModeReg.gen_int_cntl = 0;
}
/* De-allocate vertex buffers */
Yes, committed.
Keith
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
[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
[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 */
Re: [XFree86] Compilation error - X cvs
Leif Delgass wrote: On 22 Feb 2003, Michel Dänzer wrote: On Sam, 2003-02-22 at 19:55, Yann E. MORIN wrote: On Saturday 22 February 2003 17:11, you wrote: > On Sam, 2003-02-22 at 16:55, Yann E. MORIN wrote: > > I've got an error while compiling X (from cvs 20030222.1425). There's an > > error somewhere while compiling GL.a : [--SNIP--] > Looks like you have enabled some GlxBuiltIn* build options. Those are > known to be broken and not needed anyway. OK. That was the problem. But I had also enabled GlxUseBuiltInDRIDriver that would eventually cause glxinfo and glxgears to not compile. I removed that as well, and here we go, I have a brand new X server! Great! Thanks for the tip. I will try the new server right now. Anyway I wanted to have GLx to be as effective as possible, and, from what I understood, thought that by enabling DRI in GLx I would gain some perfs. That's BuildXF86DRI. About those options : GlxBuiltIn* and GlxUseBuiltInDRIDriver -> What do you mean by '...and not needed anyway'? -> What were they supposed to enable/disable? -> What is the impact of not enabling those? I don't know exactly what they're for, the host.def shipped in the DRI CVS tree suggests that they might help for debugging some problems, but I've never needed them, and they've been broken for a long time (lib/GL/mesa/dri was moved to lib/GL/dri) without many complaints. :) IIRC, these options were intended to allow debugging/profiling by building libGL with one of the hardware-specific DRI drivers statically linked rather than being loaded dynamically. However, this build option is broken, as you discovered. I found oprofile easier to use for profiling anyway. I suppose this should either be fixed or removed as an option at some point. I'm happy to see it removed any time. Keith ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
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
