Re: [Dri-devel] radeon cvs problem
Dear Keith - This is interesting. The code to cope with multiple contexts there hasn't had a huge amount of testing. If I download your code, how can I exercise this problem? Thanks for offering to look at this. Here's how to reproduce the problem. First download the i386 executable from: http://svr-www.eng.cam.ac.uk/~rwp/stradx/installing_stradx_lnx.html Should work out of box, though you'll need a libXm.so.1 from Lesstif (included in most recent linux distros, but not older ones). Start stradx, then open the Image correlation window from the Calibration menu, then open the Segmentation controls window from the Segmentation menu. That's when I get the assertion failure. Poking around in the source, the assertion failure happens in the call to GLwDrawingAreaMakeCurrent (aka glxMakeCurrent) when the second window is initialising. Anyone got any idea what's wrong with the SF binaries? I suspect there would be much more useful testing of the CVS drivers if the binaries worked! Cheers, Andrew --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon cvs problem
On Sun, Jun 23, 2002 at 09:12:08AM +0100, [EMAIL PROTECTED] wrote: ... Anyone got any idea what's wrong with the SF binaries? I suspect there would be much more useful testing of the CVS drivers if the binaries worked! Cheers, Andrew On the 10th of June I updated the system where the snapshopts are being made from RHL 7.1 to 7.3. This also means that XFree86 got updated from 4.1.0 to 4.2.0 and this somehow affected the binaries. To build DRI from CVS the system XFree86 headers are used. Although I merge the DRI CVS with the XFree86 4.2.0 release when building this doesn't seem to work 100%. The fact the the DRI CVS isn't self sufficient has been a major PITA (e.g., to get the binary snapshots building from the CF) and it will always be until the build process is independent of the host machine. I've disabled the merge with the XFree86 4.2.0 code to see if that helps and fired up a new build. Please check if the next binaries are ok. José Fonseca --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon cvs problem
On Wed, 2002-06-19 at 17:53, [EMAIL PROTECTED] wrote: Just upgraded to the latest radeon dri-cvs (using the binary packages on SF) and now the X server won't start. This used to work fine with the 20 May TCL snapshot. The kernel module seems to load OK: Jun 19 16:30:36 localhost kernel: [drm] AGP 0.99 on Unknown @ 0xec00 64MB Jun 19 16:30:36 localhost kernel: [drm] Initialized radeon 1.3.1 20020611 on minor 0 but the X server crashes. A full XFree86.0.log is below. For comparison, the 20 May TCL produces an identical log (up to the moment it crashes) apart from: 462,468d461 (II) Loading sub module shadow (II) LoadModule: shadow (II) Loading /usr/X11R6/lib/modules/libshadow.a (II) Module shadow: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 ABI class: XFree86 ANSI C Emulation, version 0.1 (**) RADEON(0): Disabling page flipping 512c505 drmOpenDevice: open result is 10, (OK) --- drmOpenDevice: open result is 8, (OK) 515c508 drmOpenDevice: open result is 10, (OK) --- drmOpenDevice: open result is 8, (OK) 518,528c511,594 drmOpenDevice: open result is 10, (OK) Fatal server error: Caught signal 11. Server aborting Is there any significance in the different return value from drmOpenDevice? Hardly. I was wondering how I managed to break it this time. :) But it works fine on the Athlon box at work. If you're running XFree86 4.1, Keith mentioned that the TCL stuff doesn't work with that. The TCL snapshots from TG contained a hack to work around that. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon cvs problem
If you're running XFree86 4.1, No, I'm running 4.2. Yesterday I bit the bullet and downloaded the entire source tree (quite an adventure down a phone line ...) and built from source. All worked fine this time, so there perhaps some problem with the binary packages on SF? Perhaps there's a dependence on an X11R6 module not included in the binary package? Anyhow, so now I have the radeon cvs built and working correctly, everything's wonderful (thanks to all the developers!) apart from an assertion failure I get repeatedly with our 3D ultrasound application (http://svr-www.eng.cam.ac.k/~rwp/stradx). It happens whenever I open a new window and make the new context current: radeon_vtxfmt.c:1039: radeonVtxfmtUnbindContext: Assertion `vb.context == ctx' failed. It doesn't happen with _every_ context switch, just with a particular pair of windows in the application - but it is repeatable with these two windows. The problem goes away with RADEON_NO_TCL=1 or RADEON_NO_VTXFMT=1, and doesn't appear with any other GL implementation we've tried (including mga dri). I'd be happy to test patches if anyone's interested in this one Cheers, Andrew PS. Just read Konstantin's post, so it's looking like there's definitely a problem with the cvs binaries! --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon cvs problem
On Saturday 22 June 2002 21:41, Keith Whitwell wrote: [EMAIL PROTECTED] wrote: If you're running XFree86 4.1, No, I'm running 4.2. Yesterday I bit the bullet and downloaded the entire source tree (quite an adventure down a phone line ...) and built from source. All worked fine this time, so there perhaps some problem with the binary packages on SF? Perhaps there's a dependence on an X11R6 module not included in the binary package? Anyhow, so now I have the radeon cvs built and working correctly, everything's wonderful (thanks to all the developers!) apart from an assertion failure I get repeatedly with our 3D ultrasound application (http://svr-www.eng.cam.ac.k/~rwp/stradx). It happens whenever I open a new window and make the new context current: radeon_vtxfmt.c:1039: radeonVtxfmtUnbindContext: Assertion `vb.context == ctx' failed. It doesn't happen with _every_ context switch, just with a particular pair of windows in the application - but it is repeatable with these two windows. The problem goes away with RADEON_NO_TCL=1 or RADEON_NO_VTXFMT=1, and doesn't appear with any other GL implementation we've tried (including mga dri). I'd be happy to test patches if anyone's interested in this one This is interesting. The code to cope with multiple contexts there hasn't had a huge amount of testing. If I download your code, how can I exercise this problem? What about the cxbug.c test posted here, lately? With the tdfx driver I get this with mode #5: Mesa/demos ./cxbug 5 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 10 (X_GLXCopyContext) Serial number of failed request: 37 Current serial number in output stream: 38 Manywin show bad textures with s = 2 Mesa/xdemos ./wincopy glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() [snip] -Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: [EMAIL PROTECTED] cxbug.c.bz2 Description: BZip2 compressed data
