[Dri-devel] can't remove files from trunk
There are files left over in the bsd DRM's driver subdirectories after the merge to trunk. These got moved a directory above that (or to shared/drm/kernel/), but the leftovers are getting in the way. I tried to cvs rm and commit, but I got the following: cvs server: failed to remove tag `HEAD' from `gamma/gamma_dma.c' cvs server: failed to remove tag `HEAD' from `gamma/gamma_drv.c' cvs server: failed to remove tag `HEAD' from `i810/i810_dma.c' cvs server: failed to remove tag `HEAD' from `i810/i810_drv.c' cvs server: failed to remove tag `HEAD' from `i830/i830_dma.c' cvs server: failed to remove tag `HEAD' from `i830/i830_drv.c' cvs server: failed to remove tag `HEAD' from `mga/mga_dma.c' cvs server: failed to remove tag `HEAD' from `mga/mga_drv.c' cvs server: failed to remove tag `HEAD' from `mga/mga_state.c' cvs server: failed to remove tag `HEAD' from `mga/mga_warp.c' cvs server: failed to remove tag `HEAD' from `r128/r128_cce.c' cvs server: failed to remove tag `HEAD' from `r128/r128_drv.c' cvs server: failed to remove tag `HEAD' from `r128/r128_state.c' cvs server: failed to remove tag `HEAD' from `radeon/radeon_cp.c' cvs server: failed to remove tag `HEAD' from `radeon/radeon_drv.c' cvs server: failed to remove tag `HEAD' from `radeon/radeon_drv.h' cvs server: failed to remove tag `HEAD' from `radeon/radeon_state.c' cvs commit: saving log message in /tmp/cvs80lKSc -- Eric Anholt <[EMAIL PROTECTED]> http://people.freebsd.org/~anholt/dri/ --- This sf.net email is sponsored by:ThinkGeek Got root? We do. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Segfault in DRIClipNotify
On Fri, 5 Jul 2002, Jens Owen wrote:
> Leif Delgass wrote:
>
> > The backtrace from the static server was the same. BTW, this might help
> > others trying to debug with a dynamic server: I removed 'Load "GLcore"'
> > from my XF86Config, because I saw that it was being reloaded by the glx
> > module anyway. Before I did that, I was getting a backtrace that was
> > wrong -- it said something about mipmaps, so I was suspicious :)
>
>
> Hmmm, I was wondering how you got such nice line numbers from the back
> trace of a dynamic server. I'm also guessing you have the version of
> gdb with the XFree86 module support.
Oh yeah, I keep forgetting that I installed that. ;)
[...]
> >>Okay, try the attached patch. I think I'll do more than this, but it
> >>would be great if you could test just this, first.
> >>
> >
> > OK, thanks. I let you know how it goes.
With one change, this fixes the problem. The AdjustFrame wrapper was
already dealt with at the beginning of the function and
pDRIPriv->wrap.AdjustFrame was set to NULL, so pScrn->AdjustFrame was
getting NULL when the wrapper was removed the second time. I just removed
the first bit of code and kept yours grouped with the other new
"unwrappings." The modified patch is attached. I'll apply this to the
mach64 branch, but I'll let you patch the trunk. Thanks for your help!
--
Leif Delgass
http://www.retinalburn.net
Index: xc/programs/Xserver/GL/dri/dri.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/GL/dri/dri.c,v
retrieving revision 1.37.20.1
diff -u -r1.37.20.1 dri.c
--- xc/programs/Xserver/GL/dri/dri.c27 Jun 2002 22:04:20 - 1.37.20.1
+++ xc/programs/Xserver/GL/dri/dri.c5 Jul 2002 23:58:19 -
@@ -417,16 +417,13 @@
DRICloseScreen(ScreenPtr pScreen)
{
DRIScreenPrivPtr pDRIPriv = DRI_SCREEN_PRIV(pScreen);
+DRIInfoPtr pDRIInfo;
drmContextPtrreserved;
int reserved_count;
if (pDRIPriv && pDRIPriv->directRenderingSupport) {
- if (pDRIPriv->wrap.AdjustFrame) {
- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
- pScrn->AdjustFrame = pDRIPriv->wrap.AdjustFrame;
- pDRIPriv->wrap.AdjustFrame = NULL;
- }
+pDRIInfo = pDRIPriv->pDriverInfo;
if (pDRIPriv->pDriverInfo->driverSwapMethod != DRI_KERNEL_SWAP) {
if (!drmRemoveSIGIOHandler(pDRIPriv->drmFD)) {
@@ -476,6 +473,27 @@
}
drmClose(pDRIPriv->drmFD);
+
+ /* Unwrap DRI Functions */
+ if (pDRIInfo->wrap.ValidateTree) {
+ pScreen->ValidateTree = pDRIPriv->wrap.ValidateTree;
+ }
+ if (pDRIInfo->wrap.PostValidateTree) {
+ pScreen->PostValidateTree = pDRIPriv->wrap.PostValidateTree;
+ }
+ if (pDRIInfo->wrap.WindowExposures) {
+ pScreen->WindowExposures = pDRIPriv->wrap.WindowExposures;
+ }
+ if (pDRIInfo->wrap.CopyWindow) {
+ pScreen->CopyWindow = pDRIPriv->wrap.CopyWindow;
+ }
+ if (pDRIInfo->wrap.ClipNotify) {
+ pScreen->ClipNotify = pDRIPriv->wrap.ClipNotify;
+ }
+ if (pDRIInfo->wrap.AdjustFrame) {
+ ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
+ pScrn->AdjustFrame = pDRIPriv->wrap.AdjustFrame;
+ }
xfree(pDRIPriv);
pScreen->devPrivates[DRIScreenPrivIndex].ptr = NULL;
Re: [Dri-devel] Segfault in DRIClipNotify
Leif Delgass wrote:
> On Fri, 5 Jul 2002, Jens Owen wrote:
>
> [...]
>
The xc/config/cf/host.def in the DRI tree is setup to easily modified to
build a debuggable server. Attached is a copy of a modified host.def
file I used for debugging an i810 problem. You'll probably need to add
the mach64 driver to these options.
>>>OK, I'll try this. I think you're right that we need to add the
>>>GlxBuiltIn.. option for mach64.
>>>
>>
>>If my memory serves me, that's just for 3D clients, and it doesn't work
>>anymore...so I wouldn't worry about that option. However, you will want
>>to add mach64 to the other driver lists in this file.
>>
>
> You're right, it's for building a libGL with the driver statically linked.
> I did find where the build problem is, though. In xc/lib/GL/GL/Imakefile,
> when I added GlxBuiltInMach64, based on the r128 and Radeon, I was getting
> "No rule to make target ../../../lib/GL/mesa/dri/?*.o" in xc/lib/GL/GL.
> It looks like the xc/lib/GL/mesa/dri directory was removed and dri_util.c
> was added to xc/lib/GL/dri. I don't know if this is the right solution,
> but I took a guess and was able to get it to build with this change:
>
> Index: Imakefile
> ===
> RCS file: /cvsroot/dri/xc/xc/lib/GL/GL/Imakefile,v
> retrieving revision 1.1.1.2.12.1
> diff -u -r1.1.1.2.12.1 Imakefile
> --- Imakefile 27 Jun 2002 22:04:03 - 1.1.1.2.12.1
> +++ Imakefile 5 Jul 2002 23:01:58 -
> @@ -65,10 +65,10 @@
> MESADOBJS = $(COREMESADOBJS) $(MESA_ASM_DOBJS)
> MESAPOBJS = $(COREMESAPOBJS) $(MESA_ASM_POBJS)
>
> - DRIMESAOBJS = $(GLXLIBSRC)/mesa/dri/?*.o
> -DRIMESAUOBJS = $(GLXLIBSRC)/mesa/dri/unshared/?*.o
> -DRIMESADOBJS = $(GLXLIBSRC)/mesa/dri/debugger/?*.o
> -DRIMESAPOBJS = $(GLXLIBSRC)/mesa/dri/profiled/?*.o
> + DRIMESAOBJS = $(GLXLIBSRC)/dri/dri_util.o
> +DRIMESAUOBJS = $(GLXLIBSRC)/dri/unshared/dri_util.o
> +DRIMESADOBJS = $(GLXLIBSRC)/dri/debugger/dri_util.o
> +DRIMESAPOBJS = $(GLXLIBSRC)/dri/profiled/dri_util.o
>
> #if GlxUseBuiltInDRIDriver
> #include "../mesa/src/drv/common/Imakefile.inc"
Check with Keith to see if this stuff is worth fixing. If so,
great...if not, we ought to remove it as cruft.
>Meanwhile, here's a backtrace from the X server built from the branch. It
>looks like the ClipNotify wrapper is being called when pDRIPriv is null,
>though I'm not sure why I wouldn't have run into this before...
>
>Program received signal SIGSEGV, Segmentation fault.
>DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
>1732if(pDRIPriv->wrap.ClipNotify) {
>(gdb) bt
>#0 DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
>#1 0x080c9009 in MapWindow (pWin=0x85d3a60, client=0x81d56a8) at window.c:2864
>#2 0x080c5ee8 in InitRootWindow (pWin=0x85d3a60) at window.c:522
>#3 0x080bf39c in main (argc=4, argv=0xb9d4, envp=0xb9e8) at main.c:439
>#4 0x40072647 in __libc_start_main (main=0x80bee9c , argc=4,
> ubp_av=0xb9d4, init=0x806cc08 <_init>, fini=0x8174c80 <_fini>,
> rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xb9cc)
> at ../sysdeps/generic/libc-start.c:129
>(gdb) info locals
>pWin = 0x85d3a60
>pScreen = 0x85d3748
>pDRIPriv = 0x0
>pDRIDrawablePriv = 0x0
>
>
> The backtrace from the static server was the same. BTW, this might help
> others trying to debug with a dynamic server: I removed 'Load "GLcore"'
> from my XF86Config, because I saw that it was being reloaded by the glx
> module anyway. Before I did that, I was getting a backtrace that was
> wrong -- it said something about mipmaps, so I was suspicious :)
Hmmm, I was wondering how you got such nice line numbers from the back
trace of a dynamic server. I'm also guessing you have the version of
gdb with the XFree86 module support.
Yes, it looks like the DRI initialization process was started, causing
the DRI wrappers to be put in place; then, something caused DRI
initialization to fail, but the failure handling code does not remove
the wrappers.
I believe I need to unwrap the DRI routines in DRICloseScreen. I'd like
to fix this case and ask you to test with what you've got since it's
hard to test these unusual failure cases when everythings working properly.
It's still curious no other drivers have had this problem. Either
nobody else has gone done these failure cases, or I'm barking up the
wrong tree.
>>>It's pretty easy to test if you just change the return value of the
>>>driver's drm init function to return non-zero. For example, I tried this
>>>in the r128 driver in r128_do_init_cce (changed the last line to return
>>>-1), and it suffers the same problem (the backtrace was the same).
>>>
>>
>>Yes, it's easy for force specific failures; but I don't think developers
>>and users have been hitting the
Re: [Dri-devel] Core dumped
On Fri, 2002-07-05 at 17:00, Simon Cahuk wrote: > I get seg fault (core dumped) running glxgears. > System: > FreeBSD 4.5-RELEASE, cards banshee, using glide3 ports. > Glxinfo says DRI is enabled. Which exact version of glide3? What compile flags did you give? Did it spew any error messages before dying? (be sure to use LIBGL_DEBUG=verbose) People have had banshees working on fbsd before. One thing that some have had to do is: export FX_GLIDE_NUM_TMU=2 before running their apps. If you needed it too, I'll try to check in a fix for the port. -- Eric Anholt <[EMAIL PROTECTED]> http://people.freebsd.org/~anholt/dri/ --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: bsd-3-0-0-branch)
On Friday 05 July 2002 10:39, Alan Hourihane wrote: > On Fri, Jul 05, 2002 at 12:26:28 +0100, Keith Whitwell wrote: > > >>With this, I think it's time to merge. Would anyone else be willing to > > >>do it? (since I missed some stuff last time, like those id changes. > > >>I'm not sure how those are to be dealt with). > > > > > >Actually, Before I do this. Have you got the latest updates that > > >Keith's recently done ? > > > > I'm happy for the merge to take place. I can check the trunk once it's > > done & verify all my recent changes are there. > > O.k. The merge is done. But I've not build tested it yet. Works OK for tdfx V5 5500 (Linux). -Dieter --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Segfault in DRIClipNotify
On Fri, 5 Jul 2002, Jens Owen wrote:
[...]
> >>The xc/config/cf/host.def in the DRI tree is setup to easily modified to
> >>build a debuggable server. Attached is a copy of a modified host.def
> >>file I used for debugging an i810 problem. You'll probably need to add
> >>the mach64 driver to these options.
> >>
> >
> > OK, I'll try this. I think you're right that we need to add the
> > GlxBuiltIn.. option for mach64.
>
>
> If my memory serves me, that's just for 3D clients, and it doesn't work
> anymore...so I wouldn't worry about that option. However, you will want
> to add mach64 to the other driver lists in this file.
You're right, it's for building a libGL with the driver statically linked.
I did find where the build problem is, though. In xc/lib/GL/GL/Imakefile,
when I added GlxBuiltInMach64, based on the r128 and Radeon, I was getting
"No rule to make target ../../../lib/GL/mesa/dri/?*.o" in xc/lib/GL/GL.
It looks like the xc/lib/GL/mesa/dri directory was removed and dri_util.c
was added to xc/lib/GL/dri. I don't know if this is the right solution,
but I took a guess and was able to get it to build with this change:
Index: Imakefile
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/GL/Imakefile,v
retrieving revision 1.1.1.2.12.1
diff -u -r1.1.1.2.12.1 Imakefile
--- Imakefile 27 Jun 2002 22:04:03 - 1.1.1.2.12.1
+++ Imakefile 5 Jul 2002 23:01:58 -
@@ -65,10 +65,10 @@
MESADOBJS = $(COREMESADOBJS) $(MESA_ASM_DOBJS)
MESAPOBJS = $(COREMESAPOBJS) $(MESA_ASM_POBJS)
- DRIMESAOBJS = $(GLXLIBSRC)/mesa/dri/?*.o
-DRIMESAUOBJS = $(GLXLIBSRC)/mesa/dri/unshared/?*.o
-DRIMESADOBJS = $(GLXLIBSRC)/mesa/dri/debugger/?*.o
-DRIMESAPOBJS = $(GLXLIBSRC)/mesa/dri/profiled/?*.o
+ DRIMESAOBJS = $(GLXLIBSRC)/dri/dri_util.o
+DRIMESAUOBJS = $(GLXLIBSRC)/dri/unshared/dri_util.o
+DRIMESADOBJS = $(GLXLIBSRC)/dri/debugger/dri_util.o
+DRIMESAPOBJS = $(GLXLIBSRC)/dri/profiled/dri_util.o
#if GlxUseBuiltInDRIDriver
#include "../mesa/src/drv/common/Imakefile.inc"
> >>>Meanwhile, here's a backtrace from the X server built from the branch. It
> >>>looks like the ClipNotify wrapper is being called when pDRIPriv is null,
> >>>though I'm not sure why I wouldn't have run into this before...
> >>>
> >>>Program received signal SIGSEGV, Segmentation fault.
> >>>DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
> >>>1732if(pDRIPriv->wrap.ClipNotify) {
> >>>(gdb) bt
> >>>#0 DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
> >>>#1 0x080c9009 in MapWindow (pWin=0x85d3a60, client=0x81d56a8) at window.c:2864
> >>>#2 0x080c5ee8 in InitRootWindow (pWin=0x85d3a60) at window.c:522
> >>>#3 0x080bf39c in main (argc=4, argv=0xb9d4, envp=0xb9e8) at main.c:439
> >>>#4 0x40072647 in __libc_start_main (main=0x80bee9c , argc=4,
> >>>ubp_av=0xb9d4, init=0x806cc08 <_init>, fini=0x8174c80 <_fini>,
> >>>rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xb9cc)
> >>>at ../sysdeps/generic/libc-start.c:129
> >>>(gdb) info locals
> >>>pWin = 0x85d3a60
> >>>pScreen = 0x85d3748
> >>>pDRIPriv = 0x0
> >>>pDRIDrawablePriv = 0x0
The backtrace from the static server was the same. BTW, this might help
others trying to debug with a dynamic server: I removed 'Load "GLcore"'
from my XF86Config, because I saw that it was being reloaded by the glx
module anyway. Before I did that, I was getting a backtrace that was
wrong -- it said something about mipmaps, so I was suspicious :)
> >>Yes, it looks like the DRI initialization process was started, causing
> >>the DRI wrappers to be put in place; then, something caused DRI
> >>initialization to fail, but the failure handling code does not remove
> >>the wrappers.
> >>
> >>I believe I need to unwrap the DRI routines in DRICloseScreen. I'd like
> >>to fix this case and ask you to test with what you've got since it's
> >>hard to test these unusual failure cases when everythings working properly.
> >>
> >>It's still curious no other drivers have had this problem. Either
> >>nobody else has gone done these failure cases, or I'm barking up the
> >>wrong tree.
> >>
> >
> > It's pretty easy to test if you just change the return value of the
> > driver's drm init function to return non-zero. For example, I tried this
> > in the r128 driver in r128_do_init_cce (changed the last line to return
> > -1), and it suffers the same problem (the backtrace was the same).
>
>
> Yes, it's easy for force specific failures; but I don't think developers
> and users have been hitting these cases in normal testing scenarios.
> Otherwise, we'd have caught this during the 3 years this extensions been
> in use.
It's true that the more stable drivers wouldn't hit this very often,
but this bug wasn't present before the merge of the trunk into the mach64
branch, so it's only been around for 4 months max. The kernel init would
frequently fail when testing DMA, and the server never s
[Dri-devel] Core dumped
I get seg fault (core dumped) running glxgears. System: FreeBSD 4.5-RELEASE, cards banshee, using glide3 ports. Glxinfo says DRI is enabled. Simon --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Segfault in DRIClipNotify
Leif Delgass wrote:
> On Fri, 5 Jul 2002, Jens Owen wrote:
>
>
>>Leif Delgass wrote:
>>
>>
>>>On Fri, 5 Jul 2002, Jens Owen wrote:
>>>
>>>[snip]
>>>
>>>
>>>
However, I think you may be tickling a latent bug in the DRI. It's
possible that all the other drives have just avoided this bug so far.
I looked at DRICloseScreen and I don't see that the DRIClipNotify
wrapper is being removed. There are other unwraps missing as well.
Can you send me a back trace from a static debuggable server? Let me
know if you need help building this.
>>>Could you tell me how to build a static server or point me to a HOWTO?
>>>
>>
>>The xc/config/cf/host.def in the DRI tree is setup to easily modified to
>>build a debuggable server. Attached is a copy of a modified host.def
>>file I used for debugging an i810 problem. You'll probably need to add
>>the mach64 driver to these options.
>>
>
> OK, I'll try this. I think you're right that we need to add the
> GlxBuiltIn.. option for mach64.
If my memory serves me, that's just for 3D clients, and it doesn't work
anymore...so I wouldn't worry about that option. However, you will want
to add mach64 to the other driver lists in this file.
>
>>>Meanwhile, here's a backtrace from the X server built from the branch. It
>>>looks like the ClipNotify wrapper is being called when pDRIPriv is null,
>>>though I'm not sure why I wouldn't have run into this before...
>>>
>>>Program received signal SIGSEGV, Segmentation fault.
>>>DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
>>>1732if(pDRIPriv->wrap.ClipNotify) {
>>>(gdb) bt
>>>#0 DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
>>>#1 0x080c9009 in MapWindow (pWin=0x85d3a60, client=0x81d56a8) at window.c:2864
>>>#2 0x080c5ee8 in InitRootWindow (pWin=0x85d3a60) at window.c:522
>>>#3 0x080bf39c in main (argc=4, argv=0xb9d4, envp=0xb9e8) at main.c:439
>>>#4 0x40072647 in __libc_start_main (main=0x80bee9c , argc=4,
>>>ubp_av=0xb9d4, init=0x806cc08 <_init>, fini=0x8174c80 <_fini>,
>>>rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xb9cc)
>>>at ../sysdeps/generic/libc-start.c:129
>>>(gdb) info locals
>>>pWin = 0x85d3a60
>>>pScreen = 0x85d3748
>>>pDRIPriv = 0x0
>>>pDRIDrawablePriv = 0x0
>>>
>>
>>Yes, it looks like the DRI initialization process was started, causing
>>the DRI wrappers to be put in place; then, something caused DRI
>>initialization to fail, but the failure handling code does not remove
>>the wrappers.
>>
>>I believe I need to unwrap the DRI routines in DRICloseScreen. I'd like
>>to fix this case and ask you to test with what you've got since it's
>>hard to test these unusual failure cases when everythings working properly.
>>
>>It's still curious no other drivers have had this problem. Either
>>nobody else has gone done these failure cases, or I'm barking up the
>>wrong tree.
>>
>
> It's pretty easy to test if you just change the return value of the
> driver's drm init function to return non-zero. For example, I tried this
> in the r128 driver in r128_do_init_cce (changed the last line to return
> -1), and it suffers the same problem (the backtrace was the same).
Yes, it's easy for force specific failures; but I don't think developers
and users have been hitting these cases in normal testing scenarios.
Otherwise, we'd have caught this during the 3 years this extensions been
in use.
>>Can you verify that we are indeed calling DRICloseScreen by putting a
>>breakpoint at that routine and sending me a backtrace at that point?
>>
>
> I know it's called because I see the messages in the X log about removing
> the signal handler, kernel context, SAREA, etc. It's called as part of
> the DRI driver specific CloseScreen (ATIDRICloseScreen) when the kernel
> init fails (which is after DRIFinishScreenInit is called). In fact, the
> entire X init seems to work without a hitch (I see all the normal messages
> in the X log after "Direct rendering disabled" up to XINPUT) until the
> root window is initialized.
Okay, try the attached patch. I think I'll do more than this, but it
would be great if you could test just this, first.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
--- xc/programs/Xserver/GL/dri/dri.c.jens Fri Jul 5 13:07:43 2002
+++ xc/programs/Xserver/GL/dri/dri.cFri Jul 5 16:27:11 2002
@@ -417,11 +417,14 @@
DRICloseScreen(ScreenPtr pScreen)
{
DRIScreenPrivPtr pDRIPriv = DRI_SCREEN_PRIV(pScreen);
+DRIInfoPtr pDRIInfo;
drmContextPtrreserved;
int reserved_count;
if (pDRIPriv && pDRIPriv->directRenderingSupport) {
+pDRIInfo = pDRIPriv->pDriverInfo;
+
if (pDRIPriv->wrap.AdjustFrame) {
ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
pScrn->AdjustFrame = pDRIPriv->wrap.AdjustFram
Re: [Dri-devel] Ann: Radeon 8500 binary snapshots now available
On Fri, 2002-07-05 at 14:55, Stefan Lange wrote: > > on more comment: xv seems to be broken, it only gives me a black overlay > window with mplayer. are there plans to merge with gatos some time? http://www.keithp.com/~keithp/download/radeon_video.diff makes Xv work with all Radeon chips. http://www.keithp.com/~keithp/download/radeon_xv-2002-03-29-19.diff fixes the color key problems. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] radeon 8500 driver crash
Hi, I have been playing with the new binary radeon 8500 drivers. Most applications work fine but I have experienced problems with the following applications: o RTCW: A lot slower that with my old banshee but that could just be because I am running out of memory (128Mo is obviously not enough with 32bit textures). Random crashes but they do not freeze the system. o Myth2 (1.3e): The menu works fine (not GL) but my system freezes hard when I enter the game --> reboot :-( o atlantis (and other demos from xscreensaver-gl) works fine with the default settings but freezes after a few seconds with the options "-fps -delay 0" --> reboot :-( That's all. Continue the good work guys. S. --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Segfault in DRIClipNotify
On Fri, 5 Jul 2002, Jens Owen wrote:
> Leif Delgass wrote:
>
> > On Fri, 5 Jul 2002, Jens Owen wrote:
> >
> > [snip]
> >
> >
> >>However, I think you may be tickling a latent bug in the DRI. It's
> >>possible that all the other drives have just avoided this bug so far.
> >>
> >>I looked at DRICloseScreen and I don't see that the DRIClipNotify
> >>wrapper is being removed. There are other unwraps missing as well.
> >>
> >>Can you send me a back trace from a static debuggable server? Let me
> >>know if you need help building this.
> >>
> >
> > Could you tell me how to build a static server or point me to a HOWTO?
>
>
> The xc/config/cf/host.def in the DRI tree is setup to easily modified to
> build a debuggable server. Attached is a copy of a modified host.def
> file I used for debugging an i810 problem. You'll probably need to add
> the mach64 driver to these options.
OK, I'll try this. I think you're right that we need to add the
GlxBuiltIn.. option for mach64.
> > Meanwhile, here's a backtrace from the X server built from the branch. It
> > looks like the ClipNotify wrapper is being called when pDRIPriv is null,
> > though I'm not sure why I wouldn't have run into this before...
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
> > 1732if(pDRIPriv->wrap.ClipNotify) {
> > (gdb) bt
> > #0 DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
> > #1 0x080c9009 in MapWindow (pWin=0x85d3a60, client=0x81d56a8) at window.c:2864
> > #2 0x080c5ee8 in InitRootWindow (pWin=0x85d3a60) at window.c:522
> > #3 0x080bf39c in main (argc=4, argv=0xb9d4, envp=0xb9e8) at main.c:439
> > #4 0x40072647 in __libc_start_main (main=0x80bee9c , argc=4,
> > ubp_av=0xb9d4, init=0x806cc08 <_init>, fini=0x8174c80 <_fini>,
> > rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xb9cc)
> > at ../sysdeps/generic/libc-start.c:129
> > (gdb) info locals
> > pWin = 0x85d3a60
> > pScreen = 0x85d3748
> > pDRIPriv = 0x0
> > pDRIDrawablePriv = 0x0
>
>
> Yes, it looks like the DRI initialization process was started, causing
> the DRI wrappers to be put in place; then, something caused DRI
> initialization to fail, but the failure handling code does not remove
> the wrappers.
>
> I believe I need to unwrap the DRI routines in DRICloseScreen. I'd like
> to fix this case and ask you to test with what you've got since it's
> hard to test these unusual failure cases when everythings working properly.
>
> It's still curious no other drivers have had this problem. Either
> nobody else has gone done these failure cases, or I'm barking up the
> wrong tree.
It's pretty easy to test if you just change the return value of the
driver's drm init function to return non-zero. For example, I tried this
in the r128 driver in r128_do_init_cce (changed the last line to return
-1), and it suffers the same problem (the backtrace was the same).
> Can you verify that we are indeed calling DRICloseScreen by putting a
> breakpoint at that routine and sending me a backtrace at that point?
I know it's called because I see the messages in the X log about removing
the signal handler, kernel context, SAREA, etc. It's called as part of
the DRI driver specific CloseScreen (ATIDRICloseScreen) when the kernel
init fails (which is after DRIFinishScreenInit is called). In fact, the
entire X init seems to work without a hitch (I see all the normal messages
in the X log after "Direct rendering disabled" up to XINPUT) until the
root window is initialized.
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Segfault in DRIClipNotify
Leif Delgass wrote:
> On Fri, 5 Jul 2002, Jens Owen wrote:
>
> [snip]
>
>
>>However, I think you may be tickling a latent bug in the DRI. It's
>>possible that all the other drives have just avoided this bug so far.
>>
>>I looked at DRICloseScreen and I don't see that the DRIClipNotify
>>wrapper is being removed. There are other unwraps missing as well.
>>
>>Can you send me a back trace from a static debuggable server? Let me
>>know if you need help building this.
>>
>
> Could you tell me how to build a static server or point me to a HOWTO?
The xc/config/cf/host.def in the DRI tree is setup to easily modified to
build a debuggable server. Attached is a copy of a modified host.def
file I used for debugging an i810 problem. You'll probably need to add
the mach64 driver to these options.
> Meanwhile, here's a backtrace from the X server built from the branch. It
> looks like the ClipNotify wrapper is being called when pDRIPriv is null,
> though I'm not sure why I wouldn't have run into this before...
>
> Program received signal SIGSEGV, Segmentation fault.
> DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
> 1732if(pDRIPriv->wrap.ClipNotify) {
> (gdb) bt
> #0 DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
> #1 0x080c9009 in MapWindow (pWin=0x85d3a60, client=0x81d56a8) at window.c:2864
> #2 0x080c5ee8 in InitRootWindow (pWin=0x85d3a60) at window.c:522
> #3 0x080bf39c in main (argc=4, argv=0xb9d4, envp=0xb9e8) at main.c:439
> #4 0x40072647 in __libc_start_main (main=0x80bee9c , argc=4,
> ubp_av=0xb9d4, init=0x806cc08 <_init>, fini=0x8174c80 <_fini>,
> rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xb9cc)
> at ../sysdeps/generic/libc-start.c:129
> (gdb) info locals
> pWin = 0x85d3a60
> pScreen = 0x85d3748
> pDRIPriv = 0x0
> pDRIDrawablePriv = 0x0
Yes, it looks like the DRI initialization process was started, causing
the DRI wrappers to be put in place; then, something caused DRI
initialization to fail, but the failure handling code does not remove
the wrappers.
I believe I need to unwrap the DRI routines in DRICloseScreen. I'd like
to fix this case and ask you to test with what you've got since it's
hard to test these unusual failure cases when everythings working properly.
It's still curious no other drivers have had this problem. Either
nobody else has gone done these failure cases, or I'm barking up the
wrong tree.
Can you verify that we are indeed calling DRICloseScreen by putting a
breakpoint at that routine and sending me a backtrace at that point?
Thanks,
Jens
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
/*
* Set this for each DRI branch. It will be appended to the XFree86 version
* information.
*/
#define XFree86CustomVersion "DRI trunk"
#define DefaultGcc2AxpOpt -O2 -mcpu=ev6
#define DefaultGcc2PpcOpt -O2 -mcpu=750
#define DefaultGcc2i386Opt -O2
#if defined(AlphaArchitecture)
# define LibraryCDebugFlags -O2 -mcpu=ev6
#elif defined(PpcArchitecture)
# define LibraryCDebugFlags -O2 -mcpu=750
#else
# define LibraryCDebugFlags -O2
#endif
#define BuildXFree86ConfigTools YES
#if defined(PpcArchitecture)
#define XF86CardDrivers ati
#define DriDrivers r128 radeon
#else
#define XF86CardDrivers tdfx i810 mga ati glint vga
#define DriDrivers tdfx mga i810 r128 radeon gamma i830 /* sis ffb */
#endif
#define GccWarningOptions -Wall -Wpointer-arith -Wstrict-prototypes \
-Wmissing-prototypes -Wmissing-declarations \
-Wnested-externs
#define DefaultCCOptions -ansi GccWarningOptions -pipe -g
#define NormalLibGlx NO
#define BuildXF86DRI YES
/* To do profiling of the dynamically loaded 'xyz_dri.so' object, turn
* this on.
* Use 'xc/lib/GL/makeprofile.sh' to make it work.
*/
/* #define GlxSoProf YES */
#ifdef GlxSoProf
# undef DefaultCCOptions
# define DefaultCCOptions -ansi GccWarningOptions -pipe -g -p
#endif
/* Optionally turn these on for debugging */
/* #define GlxBuiltInTdfx YES */
#define GlxBuiltInI810 YES
/* #define GlxBuiltInMga YES */
/* #define GlxBuiltInR128 YES */
/* #define GlxBuiltInRadeon YES */
#define DoLoadableServer NO
/* Optionally turn this on to change the place where you install the build.
* Warning: trailing blanks will cause build failures.
*/
/* #define ProjectRoot /usr/X11R6-DRI */
/* Optionally turn this on to force the kernel modules to build */
/* #define BuildXF86DRM YES */
#define XF86AFB NO
#define XnestServer NO
#define XVirtualFramebufferServer NO
/*
* Don't change anything below or the build will fail.
*/
#define BuildServersOnly YES
#define BuildLibrariesForXServers NO
#define BuildLibrariesForConfigTools NO
#define BuildXIE NO
#define BuildPexExt NO
#define XprtServer NO
#define SharedLibFont NO
Re: [Dri-devel] Segfault in DRIClipNotify
On Fri, 5 Jul 2002, Jens Owen wrote:
[snip]
> However, I think you may be tickling a latent bug in the DRI. It's
> possible that all the other drives have just avoided this bug so far.
>
> I looked at DRICloseScreen and I don't see that the DRIClipNotify
> wrapper is being removed. There are other unwraps missing as well.
>
> Can you send me a back trace from a static debuggable server? Let me
> know if you need help building this.
Could you tell me how to build a static server or point me to a HOWTO?
Meanwhile, here's a backtrace from the X server built from the branch. It
looks like the ClipNotify wrapper is being called when pDRIPriv is null,
though I'm not sure why I wouldn't have run into this before...
Program received signal SIGSEGV, Segmentation fault.
DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
1732if(pDRIPriv->wrap.ClipNotify) {
(gdb) bt
#0 DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
#1 0x080c9009 in MapWindow (pWin=0x85d3a60, client=0x81d56a8) at window.c:2864
#2 0x080c5ee8 in InitRootWindow (pWin=0x85d3a60) at window.c:522
#3 0x080bf39c in main (argc=4, argv=0xb9d4, envp=0xb9e8) at main.c:439
#4 0x40072647 in __libc_start_main (main=0x80bee9c , argc=4,
ubp_av=0xb9d4, init=0x806cc08 <_init>, fini=0x8174c80 <_fini>,
rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xb9cc)
at ../sysdeps/generic/libc-start.c:129
(gdb) info locals
pWin = 0x85d3a60
pScreen = 0x85d3748
pDRIPriv = 0x0
pDRIDrawablePriv = 0x0
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon dualhead and DRI
Adam K Kirchhoff wrote: > Could you give a quick explanation, just for my understanding, of the > differences between the dualhead Matrox cards (which support the DRI on > the primary head) and the dualhead Radeon cards (which do not, currently). DRI requires a hardware cursor. Matrox does not support a hardware cursor on the secondary head for the G400 (which was the target when we wrote dual head support for the driver). Consequently, that driver was written to make sure the DRI was never run on the secondary head. Since the ATI driver could support DRI on the second head, it's possible that when dual head support was added, that the entire DRI was disabled for dual head. It is likely that you could get the DRI running on the primary head and disabled on the secondary head quite easily for the Radeon. This would be effectively the same mode as the matrox driver supports. Any more detailed questions on what needs to change in the Radeon would need to be addressed by the Radeon maintainers. I recommend starting with Kevin Martin, but there are others who have been deep into this driver. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon dualhead and DRI
Could you give a quick explanation, just for my understanding, of the differences between the dualhead Matrox cards (which support the DRI on the primary head) and the dualhead Radeon cards (which do not, currently). Adam On Fri, 5 Jul 2002, Jens Owen wrote: > Adam K Kirchhoff wrote: > > > Actually, Jens, I'm not even talking about getting it working with > > Xinerama. Just a traditional dualhead setup with two independent > > displays. Last time I tried this, the radeon driver disabled DRI. > > The traditional dualhead setup with two independent displays from a > single graphics chip is represented by the first diagram: > > http://www.tungstengraphics.com/dri/Multihead_DH.txt > > 2D support is in place, now. That's represented by the two "indirect > rendering" pipes that go down the middle of the diagram. This level of > sharing is achieved without the need for any DRI mechanisms (contexts, > locks, etc.). Once you enable a either of the DRI pipe (the two outside > "direct rendering" paths), you'll need to address how the DRI mechanims > will be shared across all the pipes. > > This could be a straight forward task, at least for a single DRI pipe on > the primary display. If somebody is up to flushing out this support. > Let us know. > > > Now, if I throw a PCI card into my machine, in addition to the AGP Radeon > > 7500, I can get DRI working on the Radeon 7500, and still use the PCI > > card as a secondary head. > > That is a completely different scenario because you don't have shared > render hardware and your not sharing the AGP aperature. To the DRI > drivers, it looks the same as a single headed DRI display. > > -- > /\ > Jens Owen/ \/\ _ >[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado > > --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Any interest in a face to face meeting
Jens Owen wrote: > The Linux Kongress is accepting applications for fully sponsered > workshops. This is an opportunity for OS development communities to get > together and work face to face for 3 days. See > http://www.linux-kongress.org/2002/workshops/faq.html for more details. > > If you are interested in attending a workshop like this for DRI > development, send me an e-mail. If there is enough interest, I'll send > in an application. The deadline is monday. Many thanks to those that have replied so quickly about attending at DRI session at Linux Kongress. Unfortunately, it's already clear that we would not have critical mass from the most active developers in our community. Consequently, I'm not planning on sending an application. Perhaps there will be other opportunities in the future. If you are a DRI contributer and you plan on attending SigGraph this year, let us know. We'll at least buy you lunch or dinner :-) Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Segfault in DRIClipNotify
Leif Delgass wrote: > After merging the trunk into the mach64 branch, I get a segfault in the > Xserver in DRIClipNotify (dereferences a null pointer when trying to call > a wrapper function, I think) if direct rendering is disabled after > DRIFinishScreenInit is called, e.g. if the init of the drm kernel module > fails. I tested this with Rage128 by making the cce_init return non-zero > and I get the same thing. Was there a recent change in libdri.a that > would be causing this? Leif, I spent a little time this morning looking at this. There have been a few minor changes to dri.c in the last month. It's possible that one of these is biting you: revision 1.40 date: 2002/06/12 15:50:27; author: keithw; state: Exp; lines: +16 -0 merged tcl-0-0-branch revision 1.39 date: 2002/06/02 16:00:44; author: mdaenzer; state: Exp; lines: +1 -1 fixes for big endian in general and powerpc in particular revision 1.38 date: 2002/05/28 13:45:11; author: jensowen; state: Exp; lines: +4 -0 bump clipstamp before destroying drawable However, I think you may be tickling a latent bug in the DRI. It's possible that all the other drives have just avoided this bug so far. I looked at DRICloseScreen and I don't see that the DRIClipNotify wrapper is being removed. There are other unwraps missing as well. Can you send me a back trace from a static debuggable server? Let me know if you need help building this. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] experience with the lastest cvs version for mga
Hi, the lastest cvs version crashes for me with a sig. fault when starting a gl application. After taking a deeper look into it, it seems to be a problem with the lastest changes in xc/xc/extras/Mesa/src/context.c (Tue Jun 18 03:29:39 2002 UTC (2 weeks, 3 days ago) by brianp). After checking out the older version it works again. Look like the same issures already metion for the radeon happen for the mga. wolf: Missing the mouse cursor for the first menu Preview movie of the multiplayer mission broken After a few minutes screen freezes gtkradiant: When switching texture render quality from linear to bilinear all textures are white. I'll take a look into its source code to get more information what gl commands are used. Bye, Michael --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon dualhead and DRI
Adam K Kirchhoff wrote: > Actually, Jens, I'm not even talking about getting it working with > Xinerama. Just a traditional dualhead setup with two independent > displays. Last time I tried this, the radeon driver disabled DRI. The traditional dualhead setup with two independent displays from a single graphics chip is represented by the first diagram: http://www.tungstengraphics.com/dri/Multihead_DH.txt 2D support is in place, now. That's represented by the two "indirect rendering" pipes that go down the middle of the diagram. This level of sharing is achieved without the need for any DRI mechanisms (contexts, locks, etc.). Once you enable a either of the DRI pipe (the two outside "direct rendering" paths), you'll need to address how the DRI mechanims will be shared across all the pipes. This could be a straight forward task, at least for a single DRI pipe on the primary display. If somebody is up to flushing out this support. Let us know. > Now, if I throw a PCI card into my machine, in addition to the AGP Radeon > 7500, I can get DRI working on the Radeon 7500, and still use the PCI > card as a secondary head. That is a completely different scenario because you don't have shared render hardware and your not sharing the AGP aperature. To the DRI drivers, it looks the same as a single headed DRI display. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: Radeon 8500 binary snapshots now available
Hi! I just checked out and compiled the r200-0-1-branch: >> glxgears: ~ 1650 fps > > I've just commited a small optimization that gears benefits from. It > may be quite close now... its about 1720 now ;-) [...] > > A large part of this difference is presumably due to HyperZ - something > that we can't implement in an open driver. what is hyper-z? a proprietary texture-compression function of the r200? well, as you expected, performance is exactly the same after the checkout as before > >> rtcw (single player): working, but quite slow (performance isn't really >> great with firegl-drivers neither...), crashed after about 10 mins > > > Yes, I haven't had the opportunity to do any long runs of these demos. > It's a bit disappointing that they lockup, though. > I'm also still experiencing crashes with q3a and wolf, after some minutes of playing. Is there anything I can do to help to track down the reason (i have to warn you though: i don't have any programming or debugging experience)? oh yeah, one other thing: in the other mail I reported that xv is broken: it works fine now for me, so I somehow messed it up before. sorry about that > Keith > > > > > --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Any interest in a face to face meeting
Jens Owen wrote: > The Linux Kongress is accepting applications for fully sponsered > workshops. This is an opportunity for OS development communities to get > together and work face to face for 3 days. See > http://www.linux-kongress.org/2002/workshops/faq.html for more details. > > If you are interested in attending a workshop like this for DRI > development, send me an e-mail. If there is enough interest, I'll send > in an application. The deadline is monday. It's a slightly bad time for me -- I'll be hiking in France that week. Keith --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Any interest in a face to face meeting
The Linux Kongress is accepting applications for fully sponsered workshops. This is an opportunity for OS development communities to get together and work face to face for 3 days. See http://www.linux-kongress.org/2002/workshops/faq.html for more details. If you are interested in attending a workshop like this for DRI development, send me an e-mail. If there is enough interest, I'll send in an application. The deadline is monday. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
