Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?
Slava Polyakov wrote: 2.4.19-pre10: version: 0.99 bridge id: 0x11308086 agp_mode: 0x1f000207 aper_base: 0xd800 aper_size: 64 pg_total: 82176 pg_system: 82176 pg_used: 0 entry.key : 0 entry.key : 1 Allocated 8 megs of GART memory MemoryBenchmark: 521 mb/s MemoryBenchmark: 606 mb/s MemoryBenchmark: 606 mb/s Average speed: 577 mb/s Testing data integrity (1st pass): passed on first pass. Testing data integrity (2nd pass): passed on second pass. That's OK. 2.4.19-rc1 open: no such device apprently i815 agp support got broken in 2.4.19-rc1. Yep, looks like something went wrong. I don't see any blatant error at the moment... Do you see something strange in your logs when doing a 'modprobe agpgart' ? And maybe also send the output of 'lspci -nv', just to be sure a+ -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) Office: ELE 237 Phone: +41 - 21 - 693 36 32 (LTS Office) Fax: +41 - 21 - 693 76 00 Web: http://ltswww.epfl.ch/~aspert --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Save Big with steep declines in interest rates 0635WwjX2-556j-13
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00B7_44E11C5B.D0815A74
Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?
On June 26, 2002 02:29 am, Nicolas Aspert wrote: Slava Polyakov wrote: 2.4.19-pre10: version: 0.99 bridge id: 0x11308086 agp_mode: 0x1f000207 aper_base: 0xd800 aper_size: 64 pg_total: 82176 pg_system: 82176 pg_used: 0 entry.key : 0 entry.key : 1 Allocated 8 megs of GART memory MemoryBenchmark: 521 mb/s MemoryBenchmark: 606 mb/s MemoryBenchmark: 606 mb/s Average speed: 577 mb/s Testing data integrity (1st pass): passed on first pass. Testing data integrity (2nd pass): passed on second pass. That's OK. 2.4.19-rc1 open: no such device apprently i815 agp support got broken in 2.4.19-rc1. Yep, looks like something went wrong. I don't see any blatant error at the moment... Do you see something strange in your logs when doing a 'modprobe agpgart' ? And maybe also send the output of 'lspci -nv', just to be sure a+ Nope... dmesg shows all the same with both kernels: [drm] AGP 0.99 on Intel i815 @ 0xd800 64MB [drm] Initialized radeon 1.3.0 20020521 on minor 0 and here is the lspci: 00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 04) Subsystem: ABIT Computer Corp.: Unknown device 0407 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Region 0: Memory at d800 (32-bit, prefetchable) [size=64M] Capabilities: available only to root 00:01.0 PCI bridge: Intel Corp.: Unknown device 1131 (rev 04) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: c000-cfff Memory behind bridge: dc00-ddff Prefetchable memory behind bridge: d000-d7ff BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- Reset- FastB2B- 00:1e.0 PCI bridge: Intel Corp. 82820 820 (Camino 2) Chipset PCI (rev 11) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=32 I/O behind bridge: a000-bfff Memory behind bridge: de00-dfff Prefetchable memory behind bridge: e000-e00f BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- Reset- FastB2B- 00:1f.0 ISA bridge: Intel Corp. 82820 820 (Camino 2) Chipset ISA Bridge (ICH2) (rev 11) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 00:1f.1 IDE interface: Intel Corp. 82820 820 (Camino 2) Chipset IDE U100 (rev 11) (prog-if 80 [Master]) Subsystem: ABIT Computer Corp.: Unknown device 0407 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Region 4: I/O ports at f000 [size=16] 00:1f.2 USB Controller: Intel Corp. 82820 820 (Camino 2) Chipset USB (Hub A) (rev 11) (prog-if 00 [UHCI]) Subsystem: ABIT Computer Corp.: Unknown device 0407 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin D routed to IRQ 10 Region 4: I/O ports at d000 [size=32] 00:1f.3 SMBus: Intel Corp. 82820 820 (Camino 2) Chipset SMBus (rev 11) Subsystem: ABIT Computer Corp.: Unknown device 0407 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin B routed to IRQ 3 Region 4: I/O ports at 5000 [size=16] 00:1f.4 USB Controller: Intel Corp. 82820 820 (Camino 2) Chipset USB (Hub B) (rev 11) (prog-if 00 [UHCI]) Subsystem: ABIT Computer Corp.: Unknown device 0407 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin C routed to IRQ 11 Region 4: I/O ports at d400 [size=32] 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon QD (prog-if 00 [VGA])
Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?
Slava Polyakov wrote: Nope... dmesg shows all the same with both kernels: [drm] AGP 0.99 on Intel i815 @ 0xd800 64MB [drm] Initialized radeon 1.3.0 20020521 on minor 0 Can you extract the agpgart bits from /var/log/messages (the drm is a different part) ? It should look like : Jun 10 17:09:09 ltslinux34 kernel: agpgart: Maximum main memory to use for agp memory: 203M Jun 10 17:09:09 ltslinux34 kernel: agpgart: agpgart: Detected an Intel i815, but could not find the secondary device. Assuming a non-integrated video card. Jun 10 17:09:09 ltslinux34 kernel: agpgart: Detected Intel i815 chipset Jun 10 17:09:09 ltslinux34 kernel: agpgart: AGP aperture is 64M @ 0xf800 a+ -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Failure to build the s3virge-0-0-1-branch
Last night the script tried to build the s3virge binary snapshot for the first time, but it failed when building a file related with the i830 driver: gcc -O2 -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -g -fno-merge-constants -I../../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../../programs/Xserver/hw/xfree86/os-support -I. -I../../../../../../../programs/Xserver/include -I../../../../../../../exports/include/X11 -I../../../../../../../include/extensions -I../.. -Ikernel -I../../../../../../.. -I../../../../../../../exports/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPANORAMIX -DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DIN_MODULE -DXFree86Module -DHAS_MTRR_SUPPORT -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -c xf86drmI830.c xf86drmI830.c: In function `drmI830CleanupDma': xf86drmI830.c:55: `drm_i830_init_t' undeclared (first use in this function) xf86drmI830.c:55: (Each undeclared identifier is reported only once xf86drmI830.c:55: for each function it appears in.) xf86drmI830.c:55: parse error before `init' xf86drmI830.c:57: `init' undeclared (first use in this function) xf86drmI830.c:60: `DRM_IOCTL_I830_INIT' undeclared (first use in this function) xf86drmI830.c: In function `drmI830InitDma': xf86drmI830.c:69: `drm_i830_init_t' undeclared (first use in this function) xf86drmI830.c:69: parse error before `init' xf86drmI830.c:71: `init' undeclared (first use in this function) xf86drmI830.c:91: `DRM_IOCTL_I830_INIT' undeclared (first use in this function) make[8]: *** [xf86drmI830.o] Error 1 rm -f xf86drmS3V.o And the packaging script fails since it can't find libdrm.a. Max, is there any file related to i830 missing or outdated in the s3virge branch? Or perhaps the i830 driver should be disabled on this branch. José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Failure to build the s3virge-0-0-1-branch
I can do the trunk merge for you, if you want to fixup the code later. Alan. On Wed, Jun 26, 2002 at 11:45:51AM +0100, José Fonseca wrote: Last night the script tried to build the s3virge binary snapshot for the first time, but it failed when building a file related with the i830 driver: gcc -O2 -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -g -fno-merge-constants -I../../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../../programs/Xserver/hw/xfree86/os-support -I. -I../../../../../../../programs/Xserver/include -I../../../../../../../exports/include/X11 -I../../../../../../../include/extensions -I../.. -Ikernel -I../../../../../../.. -I../../../../../../../exports/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPANORAMIX -DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DIN_MODULE -DXFree86Module -DHAS_MTRR_SUPPORT -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -c xf86drmI830.c xf86drmI830.c: In function `drmI830CleanupDma': xf86drmI830.c:55: `drm_i830_init_t' undeclared (first use in this function) xf86drmI830.c:55: (Each undeclared identifier is reported only once xf86drmI830.c:55: for each function it appears in.) xf86drmI830.c:55: parse error before `init' xf86drmI830.c:57: `init' undeclared (first use in this function) xf86drmI830.c:60: `DRM_IOCTL_I830_INIT' undeclared (first use in this function) xf86drmI830.c: In function `drmI830InitDma': xf86drmI830.c:69: `drm_i830_init_t' undeclared (first use in this function) xf86drmI830.c:69: parse error before `init' xf86drmI830.c:71: `init' undeclared (first use in this function) xf86drmI830.c:91: `DRM_IOCTL_I830_INIT' undeclared (first use in this function) make[8]: *** [xf86drmI830.o] Error 1 rm -f xf86drmS3V.o And the packaging script fails since it can't find libdrm.a. Max, is there any file related to i830 missing or outdated in the s3virge branch? Or perhaps the i830 driver should be disabled on this branch. José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Failure to build the s3virge-0-0-1-branch
Looks like the s3virge branch is lagging quite a bit behind the trunk. Max - you should bring in the current trunk code into your s3virge branch and fixup for the new drmCommand interface. Alan. On Wed, Jun 26, 2002 at 11:45:51AM +0100, José Fonseca wrote: Last night the script tried to build the s3virge binary snapshot for the first time, but it failed when building a file related with the i830 driver: gcc -O2 -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -g -fno-merge-constants -I../../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../../programs/Xserver/hw/xfree86/os-support -I. -I../../../../../../../programs/Xserver/include -I../../../../../../../exports/include/X11 -I../../../../../../../include/extensions -I../.. -Ikernel -I../../../../../../.. -I../../../../../../../exports/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPANORAMIX -DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DIN_MODULE -DXFree86Module -DHAS_MTRR_SUPPORT -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -c xf86drmI830.c xf86drmI830.c: In function `drmI830CleanupDma': xf86drmI830.c:55: `drm_i830_init_t' undeclared (first use in this function) xf86drmI830.c:55: (Each undeclared identifier is reported only once xf86drmI830.c:55: for each function it appears in.) xf86drmI830.c:55: parse error before `init' xf86drmI830.c:57: `init' undeclared (first use in this function) xf86drmI830.c:60: `DRM_IOCTL_I830_INIT' undeclared (first use in this function) xf86drmI830.c: In function `drmI830InitDma': xf86drmI830.c:69: `drm_i830_init_t' undeclared (first use in this function) xf86drmI830.c:69: parse error before `init' xf86drmI830.c:71: `init' undeclared (first use in this function) xf86drmI830.c:91: `DRM_IOCTL_I830_INIT' undeclared (first use in this function) make[8]: *** [xf86drmI830.o] Error 1 rm -f xf86drmS3V.o And the packaging script fails since it can't find libdrm.a. Max, is there any file related to i830 missing or outdated in the s3virge branch? Or perhaps the i830 driver should be disabled on this branch. José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Michel Dänzer wrote: On Wed, 2002-06-26 at 10:32, Keith Whitwell wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ Changes by: keithw@usw-pr-cvs1. 02/06/26 01:32:32 Log message: Fog correction Out of curiosity, what was the problem? A typo -- a malformed statement like rmesa-hw.ctx.cmd[VTX_FOO] which should have been rmesa-hw.vtx.cmd[VTX_FOO] Picked this up in the r200 driver because it was causing a malformed packet there. Keith --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Failure to build the s3virge-0-0-1-branch
On Wed, Jun 26, 2002 at 03:43:42PM +0200, Massimiliano Lingua wrote: On Wed, 2002-06-26 at 12:54, Alan Hourihane wrote: I can do the trunk merge for you, if you want to fixup the code later. Ok. It would be very nice from you. What I am supposed to do after: cvs update? So that code on my HD will get in sync with CVS? Yes. Just cvs update and that will bring in the changes. I'll do the merge now for you. Obviously this branch won't build at all until fixed up for the new drmCommand stuff. Alan. --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Failure to build the s3virge-0-0-1-branch
On Wed, 2002-06-26 at 12:45, José Fonseca wrote: Max, is there any file related to i830 missing or outdated in the s3virge branch? Or perhaps the i830 driver should be disabled on this branch. There was a stale #if 0 in drm/kernel/drm.h. Fixed now. Could you please let me know if this is enough to build things fine? It was needed to build thing against 4.1.0. Since sometimes people ask me for tarballs, and they do not have the latest code. I checked config/cf/host.def too, to see it was ok. It should just build support for s3virge. i830 was disabled both in XF86CardDrivers than DriDrivers. Why is it being built? Thanks, - max lingua --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Failure to build the s3virge-0-0-1-branch
On Wed, 2002-06-26 at 15:52, Alan Hourihane wrote: I'll do the merge now for you. Obviously this branch won't build at all until fixed up for the new drmCommand stuff. I have been away a couple of months from active development. Where could I gather more infos about drmCommand? Is it easy to understand just peeking at the code of other drivers? What are its benefits? Alan. --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: S3 VIRGE DRI in CVS now
Do you mean S3 Savage MX or is it a S3 virge MX??? Thanks, JrSky. S3 *** Virge *** MX. For Savage MX try utah. Or wait for us to code a driver ; ) Vale, - max --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Capturing debugging info without networking
i would prefer this DRI_DEBUG_DIR=/var/tmp/dri_debug_`date +%Y-%m-%d-%T` so that on sorted dir listings the most recent is always on top since this date is encoded MSB first. (textual month locales wont sort that good at all.) another two things you might want to add: /sbin/lspci -vvv $DRI_DEBUG_DIR/lspci.txt /sbin/lsmod $DRI_DEBUG_DIR/lsmod.txt do you expect this commands beeing executed as root or as a user? you might want to add some suid root detection or a su - query to the script lines. hmm, is there a way to dectect what built in or external modules a specific linux kernel does provide? why are you using for some of the redirections? what about a final bz2 tarball creation? -Original Message- From: Al Tobey [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 23:39 To: DRI Subject: [Dri-devel] Capturing debugging info without networking Here is a sort of simple shell script that I just thought of that might make people's lives a little easier. Cut paste this into a file (maybe /usr/local/bin/dri_debug.sh) and then add this line to your equivalent of /etc/rc.local: /bin/sh /usr/local/bin/dri_debug.sh to have it run at boot time to save info from the last crash. Otherwise, just run it any old time to get a snapshot of log data. If there's interest, I'll put together a nice rc script that should work on most distros for distribution with the testing binaries. This is just a mock up (I haven't even run it - I hate dog food ;) of what should be a bit more complicated and grab a few more things, but you get the idea. DRI_DEBUG_DIR=/var/tmp/dri_debug_`date +%d-%b-%Y-%T` mkdir $DRI_DEBUG_DIR cp /var/log/XFree86.0.log $DRI_DEBUG_DIR # this should work, but a grep might be better ... tail -5000 /var/log/messages $DRI_DEBUG_DIR/syslog.log cp /etc/X11/XF86Config* $DRI_DEBUG_DIR ls -l /usr/lib/libGL* $DRI_DEBUG_DIR/usr_GLFiles.txt ls -l /usr/X11R6/lib $DRI_DEBUG_DIR/X11R6_libFiles.txt ldd /usr/X11R6/bin/glxgears $DRI_DEBUG_DIR/ldd_glxgears.txt # any other files ... tar -czf $DRI_DEBUG_DIR.tar.gz $DRI_DEBUG_DIR #rm -rf $DRI_DEBUG_DIR It might be nice to patch xinitrc to do this: glxinfo /var/tmp/glxinfo.txt every time so it can be bundled up, too. Then when people start having problems, the list can expect (somewhat) consistent reports. Lemme know what you think. I take no responsibility for the meltdown of your system ;) -Al Tobey This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the Priority Health Information Services Department at (616) 942-0954. --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)
On Wed, Jun 26, 2002 at 04:00:18PM +0100, José Fonseca wrote: On Wed, Jun 26, 2002 at 07:07:00AM -0700, Alan Hourihane wrote: merge trunk into s3virge branch (probably won't build at all now). Needs fixing for drmCommand interface. Er.. I was just about to suggest to do the merge in a new branch (e.g., s3virge-0-0-2-branch) to avoid leave the s3virge broken while Max is too busy to do the required changes... It shouldn't take too long to fixup. Jens did the other drivers very quickly. BTW, Alan, is the trident branch in shape for binary snapshots too, or are they already available elsewhere? No. The trident driver works, but there's no fallbacks yet and lots of stuff doesn't work. Alan. --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Fixed binaries on SF
Hi Jos?! Tuesday 25, at 09:48:20 AM you wrote: On Tue, Jun 25, 2002 at 12:06:36PM +0400, Konstantin Lepikhov wrote: Hi Jos?! Monday 24, at 10:16:51 PM you wrote: As some of you already noticed, fixed binaries - i.e, including libdri.a -, are now available on SF. When [and if] the binary compatability of libdri.a is restored, let me know and I'll restore the things as they were. Jos? Fonseca Problem is gone away for voodoo3 (again :) DRI is working again after trivial compilation installation binaries. So whats happen? What's happened was that changes in libdri.a in the Radeon tcl-0-0-branch which were after included in the trunk broke compatability with previous versions of the library so drivers after this changes require an updated libdri.a. Jos? Fonseca Bad news :( My collegue who have ATI Radeon 7500 QW (AGP) reported this: he using 20020625 snapshot from XFree86.0.log ... (II) RADEON(0): [drm] drmSetBusid failed (7, PCI:1:0:0), Permission denied (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. ... DRI still not work! PS It's not a gcc problem (because ALTLinux have the same gcc-2.96-110). -- with best regards, ICQ: 109916175 JID: [EMAIL PROTECTED] Konstantin Lepikhovmailto:[EMAIL PROTECTED] Motto: Linux is like a wigwam - no windows, no gates, apache inside! --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch:s3virge-0-0-1-branch)
On Wed, 26 Jun 2002, José Fonseca wrote: On Wed, Jun 26, 2002 at 07:07:00AM -0700, Alan Hourihane wrote: merge trunk into s3virge branch (probably won't build at all now). Needs fixing for drmCommand interface. Er.. I was just about to suggest to do the merge in a new branch (e.g., s3virge-0-0-2-branch) to avoid leave the s3virge broken while Max is too busy to do the required changes... Jose, I think now would be a good time for us to merge the trunk into a new Mach64 branch. Brian released Mesa 4.0.3 and the trunk looks like it's been updated, and we need to convert to drmCommand as well. Plus there are ppc fixes that should help with our current texture problems. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Re: Fixed binaries on SF
he using 20020625 snapshot from XFree86.0.log ... (II) RADEON(0): [drm] drmSetBusid failed (7, PCI:1:0:0), Permission denied (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. ... Huh? Hi might try as root. If it works then something with per user file permissions or sticky bits is odd. other idea: for the odd case of legacy problems i would suspect that there is an API mismatch due to file inconsistency or the drm devices just do have the device file id. (there was a change in that area some time ago.) --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Fixed binaries on SF
Hi Alexander! Wednesday 26, at 06:22:24 PM you wrote: he using 20020625 snapshot from XFree86.0.log ... (II) RADEON(0): [drm] drmSetBusid failed (7, PCI:1:0:0), Permission denied (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. ... Huh? Hi might try as root. If it works then something with per user file permissions or sticky bits is odd. other idea: for the odd case of legacy problems i would suspect that there is an API mismatch due to file inconsistency or the drm devices just do have the device file id. (there was a change in that area some time ago.) We also checking this. Please wait while we tracking all variants. I don't want bother everybody about every trifle :) -- with best regards, ICQ: 109916175 JID: [EMAIL PROTECTED] Konstantin Lepikhovmailto:[EMAIL PROTECTED] Motto: Linux is like a wigwam - no windows, no gates, apache inside! --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)
On Wed, Jun 26, 2002 at 12:16:15PM -0400, Leif Delgass wrote: [...] Jose, I think now would be a good time for us to merge the trunk into a new Mach64 branch. Brian released Mesa 4.0.3 and the trunk looks like it's been updated, and we need to convert to drmCommand as well. Plus there are ppc fixes that should help with our current texture problems. Okidoki. Feel free to start the merge whenever you want - before I join you I just want to make the changes in the DRM I promised to the PPC guys to debug the problems they've been experienced. I think that's a good idea to bump the branch number too. José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Failure to build the s3virge-0-0-1-branch
On Wed, Jun 26, 2002 at 04:31:09PM +0100, Alan Hourihane wrote: On Wed, Jun 26, 2002 at 03:59:06PM +0200, Massimiliano Lingua wrote: On Wed, 2002-06-26 at 15:52, Alan Hourihane wrote: I'll do the merge now for you. Obviously this branch won't build at all until fixed up for the new drmCommand stuff. I have been away a couple of months from active development. Where could I gather more infos about drmCommand? Is it easy to understand just peeking at the code of other drivers? What are its benefits? I'll try and give you a hand on this now. Max, It builds now, so could you 'cvs update' build, install, and check everything is working. Alan. --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Merging trunk changes into mach64 branch
On Wed, Jun 26, 2002 at 01:52:00PM -0400, Leif Delgass wrote: On Wed, 26 Jun 2002, José Fonseca wrote: On Wed, Jun 26, 2002 at 12:16:15PM -0400, Leif Delgass wrote: [...] Jose, I think now would be a good time for us to merge the trunk into a new Mach64 branch. Brian released Mesa 4.0.3 and the trunk looks like it's been updated, and we need to convert to drmCommand as well. Plus there are ppc fixes that should help with our current texture problems. Okidoki. Feel free to start the merge whenever you want - before I join you I just want to make the changes in the DRM I promised to the PPC guys to debug the problems they've been experienced. I think that's a good idea to bump the branch number too. It's been a while since I did a merge. I'm thinking I'll make the branch from the trunk (I'm checking out a fresh tree from the trunk now) and then merge in changes from mach64-0-0-4-branch once you've checked in anything you'd like to get in before the merge. Does that sound like the right way to do it? I was thinking this might be easier than merging the changes on the trunk into the branch since there's been a lot of activity on the trunk since our last branchpoint from it. Yep. That's it. Basically one needs to checkout the trunk, tag it with the new mach64-0-0-5-branch, and then merge from the old branch (by doing cvs update -r mach64-0-0-4-branch in each relevant dir). The PITA, is adding the mach64 stuff to all Makefiles because the mach64 driver was never merged back into the trunk... José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Merging trunk changes into mach64 branch
On Wed, 26 Jun 2002, José Fonseca wrote: On Wed, Jun 26, 2002 at 01:52:00PM -0400, Leif Delgass wrote: On Wed, 26 Jun 2002, José Fonseca wrote: On Wed, Jun 26, 2002 at 12:16:15PM -0400, Leif Delgass wrote: [...] Jose, I think now would be a good time for us to merge the trunk into a new Mach64 branch. Brian released Mesa 4.0.3 and the trunk looks like it's been updated, and we need to convert to drmCommand as well. Plus there are ppc fixes that should help with our current texture problems. Okidoki. Feel free to start the merge whenever you want - before I join you I just want to make the changes in the DRM I promised to the PPC guys to debug the problems they've been experienced. I think that's a good idea to bump the branch number too. It's been a while since I did a merge. I'm thinking I'll make the branch from the trunk (I'm checking out a fresh tree from the trunk now) and then merge in changes from mach64-0-0-4-branch once you've checked in anything you'd like to get in before the merge. Does that sound like the right way to do it? I was thinking this might be easier than merging the changes on the trunk into the branch since there's been a lot of activity on the trunk since our last branchpoint from it. Yep. That's it. Basically one needs to checkout the trunk, tag it with the new mach64-0-0-5-branch, and then merge from the old branch (by doing cvs update -r mach64-0-0-4-branch in each relevant dir). The PITA, is adding the mach64 stuff to all Makefiles because the mach64 driver was never merged back into the trunk... Wouldn't it be easier to do 'cvs update -j mach64-0-0-4-branch'? That should merge everthing from the branch (changes relative to the branchpoint on the trunk), and I'll just have to merge any conflicts/rejects by hand. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Merging trunk changes into mach64 branch
On Wed, Jun 26, 2002 at 02:17:26PM -0400, Leif Delgass wrote: On Wed, 26 Jun 2002, José Fonseca wrote: [...] Yep. That's it. Basically one needs to checkout the trunk, tag it with the new mach64-0-0-5-branch, and then merge from the old branch (by doing cvs update -r mach64-0-0-4-branch in each relevant dir). The PITA, is adding the mach64 stuff to all Makefiles because the mach64 driver was never merged back into the trunk... Wouldn't it be easier to do 'cvs update -j mach64-0-0-4-branch'? That should merge everthing from the branch (changes relative to the branchpoint on the trunk), and I'll just have to merge any conflicts/rejects by hand. Perhaps. What I suggested was what I've done the last time. I make no claim that is the best method since as you can see my CVS knowledge is that deep! ;-) On the other hand I could not see on the CVS manpage how the -j option would have the effect you described. Is just a matter of trying anyway. Perhaps you should try instead what is suggested on HOW TO MERGE THE TRUNK INTO YOUR BRANCH in http://dri.sf.net/doc/cvspolicy.txt . Alan, hint? (Or How have you just done now with the s3virge branch?) José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] RE: Dri-devel S3 VIRGE DRI in CVS now
On Wed, Jun 26, 2002 at 08:51:18PM +0200, Massimiliano Lingua wrote: On Wed, 2002-06-26 at 16:48, José Fonseca wrote: Are the ProSavage docs you have enough to get a good start on Savage4? their 3D engine is nearly identical. Er, I forgot, I got Savage4 docs too from S3/VIA. I am definetly the luckiest coder on Earth ; ) Well, at least someone of us has. That's good enough for me! So on a Savage4 running my hack you will see just the same as me: monochrome (black), smeared triangles ; ( I am quite busy now (I have to pass this fucking law exam...), but if you are interested in the 2nd half of July I could send you a copy of my code + some comment (it should be very intuitive even without docs), so maybe you can guess what I am doing wrong. I would appreciate it. But have no hurry because of me, since only on the 26th of July I'll have access to my Savage4 card (when I return to Portugal in vacations), so only then I'll be able to test it myself. Nevertheless it would be nice to have whatever you have in CVS - as is - so that others can start playing with it. If you want just send me the parts and I'll do the integration with the CVS myself. But only if this isn't too much trouble for you now, of course. (I don't how big is what you have nor how fast is your internet connection). José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Capturing debugging info without networking
Good boys! Can anyone invent the way to do the same thing with gdb? So on X crash one could get backtrace without remote debugging... Cheers, Sergey --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)
On Wed, Jun 26, 2002 at 10:04:27AM -0700, Alan Hourihane wrote: o.k. it's builds now, max needs to check it runs o.k. I've tested and I still get errors when building it: gcc -c -O2 -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -g -I../. ./../../../../exports/include/X11 -I../../../../../../include/extensions -I../../../../../../extras/Mesa/src-I../../../../../ ../lib/GL/mesa/src/drv/common -I../../../../../../lib/GL/mesa/src/drv/s3v -I../../../../../../lib/GL/dri -I../../. ./../../../lib/GL/glx -I../../../../../../exports/include -I../../../../../../exports/include/GL -I../../. ./../../../programs/Xserver/GL/dri -I../../../../../../programs/Xserver/hw/xfree86/os-support -I../../../../../ ../programs/Xserver/hw/xfree86/drivers/s3virge -I../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../ ../lib/GL/dri/drm -I../../../../../../lib/GL/include -I../../../../../../include -I../../../../../.. -I../../ ../../../../exports/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOU RCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API-DMALLOC_0_RETURNS_NULL -D GLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE _3DNOW_ASM -DUSE_SSE_ASM s3v_context.c In file included from s3v_context.c:5: s3v_context.h:215: parse error before `drm_s3v_sarea_t' s3v_context.h:215: warning: no semicolon at end of struct or union s3v_context.h:378: `Window' redeclared as different kind of symbol ../../../../../../exports/include/X11/X.h:101: previous declaration of `Window' s3v_context.h:403: parse error before `}' s3v_context.c: In function `s3vCreateContext': s3v_context.c:57: `drm_s3v_sarea_t' undeclared (first use in this function) s3v_context.c:57: (Each undeclared identifier is reported only once s3v_context.c:57: for each function it appears in.) s3v_context.c:57: `saPriv' undeclared (first use in this function) s3v_context.c:57: parse error before `)' s3v_context.c:62: dereferencing pointer to incomplete type ... And alot of similar errors after. Perhaps something was forgoten when commiting? José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Merging trunk changes into mach64 branch
On Wed, Jun 26, 2002 at 04:22:07PM -0400, Leif Delgass wrote: On Wed, 26 Jun 2002, Alan Hourihane wrote: On Wed, Jun 26, 2002 at 07:44:14PM +0100, José Fonseca wrote: Alan, hint? (Or How have you just done now with the s3virge branch?) cvs update -j HEAD and resolve the conflicts by hand. OK, I can do that. I guess it'll be about the same difficulty as merging the branch changes into the trunk code. Jose, do you have anything else you want to commit before I tag the new branch? I'm going to update my No. I just have the new vertex template stuff but I'm still working on it and it shouldn't be more difficult to commit directly to the new branch. mach64-0-0-4-branch tree and tag it to create the new mach64-0-0-5-branch. Then I'll merge in the trunk and start working on conflicts and the drmCommand changes. Ok. José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Annouce: S3 Virge binary snapshots (Was: CVS Update: xc (branch: s3virge-0-0-1-branch))
On Wed, Jun 26, 2002 at 08:56:04PM +0100, Alan Hourihane wrote: On Wed, Jun 26, 2002 at 08:38:03PM +0100, José Fonseca wrote: On Wed, Jun 26, 2002 at 10:04:27AM -0700, Alan Hourihane wrote: o.k. it's builds now, max needs to check it runs o.k. ... Perhaps something was forgoten when commiting? Indeed. Committed. It worked like a charm! The first s3virge binary snapshot is now available on http://dri.sourceforge.net/snapshots/bleeding-edge/ . José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] How to trace switching to software rendering
Hi Brian, sorry for disturb you again. Am Sam, 2002-06-22 um 00.00 schrieb Brian Paul: Most of the DRI drivers have a per-context field called 'Fallback'. It's a bitmask which records various reasons why we need to fallback to software rendering. In the case of the mga (G400) driver you'll see these flags in mgacontext.h: #define MGA_FALLBACK_TEXTURE0x1 #define MGA_FALLBACK_DRAW_BUFFER0x2 #define MGA_FALLBACK_READ_BUFFER0x4 #define MGA_FALLBACK_LOGICOP0x8 #define MGA_FALLBACK_RENDERMODE 0x10 #define MGA_FALLBACK_STENCIL0x20 #define MGA_FALLBACK_DEPTH 0x40 If you search the code, you'll find where we set these flags by calling mgaFallback() (via the FALLBACK() macro). You could put a printf in there to print the bit value and get an idea of what's slowing you down. Ok, I did a printf there and switch MGA_DEBUG on. Now I need a bit help with the analyse of the output... mgaFallback: bit:1 mode:0 Looks like this is a call from mgaUpdateTextureState. Since mode is 0 the fallback flag is unset? FLUSH_BATCH in mgaReadDepthPixels_16 FLUSH_BATCH in mgaWriteDepthPixels_16 FLUSH_BATCH in mgaWriteRGBAPixels_565 FLUSH_BATCH in mgaDDBindTexture FLUSH_BATCH in mgaDDUpdateHwState FLUSH_BATCH in mgaFallback FALLBACK: GL_DECAL RGBA texture, unit=0 FLUSH_BATCH in mgaReadDepthPixels_16 FLUSH_BATCH in mgaWriteDepthPixels_16 FLUSH_BATCH in mgaWriteRGBAPixels_565 This looks more interesting to me. Is there a problem with RGBA textures? Bye, Michael --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Parhelia vs. Radeon 8500
Hello, I have some money to spend (finally!!!) so I'm thinking of replacing my old G400MAX for a new card, as I prefer open source, I have to choose between ATI and Matrox, and the optios (for me) are the new Parhelia 512 or the AIW Radeon 8500 DV, I'll buy whatever card works better under Linux, as far as I know somebody is working in 3D for the 8500 even TCL!!, and the Gatos project has good quality video in/out for the AIW DV. The parhelia is quite misterious, but I could wait two or three months if the drivers would be good enough. I would like to know if anybody from Matrox contacted developers here, well, in fact, I would like to know if I should wait for the parhelia linux drivers or go for the AIW. What do you think?? Regards, - german -- Send email with SEND GPG KEY as subject to receive my GnuPG public key. --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parhelia vs. Radeon 8500
On Wed, Jun 26, 2002 at 11:22:16PM +0200, German Gomez Garcia wrote: Hello, I have some money to spend (finally!!!) so I'm thinking of replacing my old G400MAX for a new card, as I prefer open source, I have to choose between ATI and Matrox, and the optios (for me) are the new Parhelia 512 or the AIW Radeon 8500 DV, I'll buy whatever card works better under Linux, as far as I know somebody is working in 3D for the 8500 even TCL!!, and the Gatos project has good quality video in/out for the AIW DV. The parhelia is quite misterious, but I could wait two or three months if the drivers would be good enough. I would like to know if anybody from Matrox contacted developers here, well, in fact, I would like to know if I should wait for the parhelia linux drivers or go for the AIW. What do you think?? For some reviews, comparisons and discussion regarding Matrox Parhelia follow this link http://slashdot.org/article.pl?sid=02/06/25/1317222 . Regarding the availability of linux drivers check the Matrox plan at http://www.extremetech.com/article2/0,3973,182491,00.asp . Regarding the ATI Radeon 8500 I'm sure you're already aware of the Wheather Channel sponsoring the development of DRI drivers: http://slashdot.org/article.pl?sid=02/06/09/0236221 . The choice [as always] depends entirely on which factors you value the most. I hope this helps. José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[dbronaugh@linuxboxen.org: Re: [Dri-devel] Annouce: S3 Virge binary snapshots (Was: CVS Update: xc (branch: s3virge-0-0-1-branch))]
- Forwarded message from David Bronaugh [EMAIL PROTECTED] - Date: Wed, 26 Jun 2002 14:54:29 -0700 From: David Bronaugh [EMAIL PROTECTED] Subject: Re: [Dri-devel] Annouce: S3 Virge binary snapshots (Was: CVS Update: xc (branch: s3virge-0-0-1-branch)) To: Jos Fonseca [EMAIL PROTECTED] It worked like a charm! The first s3virge binary snapshot is now available on http://dri.sourceforge.net/snapshots/bleeding-edge/ . José Fonseca Trying out your binary snapshot on a Debian Potato machine without any luck. Errors are as follows when trying to build DRM: Stretch:/home/bronaugh/X11R6-DRI/dripkg/drm# make -f Makefile.linux === KERNEL HEADERS IN /lib/modules/2.4.16/build/include === SMP=0 MODULES=1 MODVERSIONS=1 AGP=0 === Compiling for machine i586 === WARNING === WARNING Use 2.4.x kernels ONLY ! === WARNING cc -O2 -Wall -Wwrite-strings -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -Wpointer-arith -D__KERNEL__ -DMODULE -fomit-frame-pointer -DCONFIG_DRM_SIS -DMODVERSIONS -include /lib/modules/2.4.16/build/include/linux/modversions.h -DEXPORT_SYMTAB -I/lib/modules/2.4.16/build/include -c s3v_drv.c -o s3v_drv.o In file included from s3v_drv.c:8: s3v_drv.h:23: parse error before `drm_s3v_sarea_t' s3v_drv.h:23: warning: no semicolon at end of struct or union s3v_drv.h:55: parse error before `}' s3v_drv.h:55: warning: type defaults to `int' in declaration of `drm_s3v_private_t' s3v_drv.h:55: warning: data definition has no type or storage class In file included from s3v_drv.c:40: drm_bufs.h: In function `s3v_mapbufs': drm_bufs.h:1055: parse error before `)' In file included from s3v_drv.c:44: drm_drv.h: At top level: drm_drv.h:209: `DRM_IOCTL_S3V_INIT' undeclared here (not in a function) drm_drv.h:209: nonconstant array index in initializer drm_drv.h:209: (near initialization for `s3v_ioctls') drm_drv.h:209: `DRM_IOCTL_S3V_RESET' undeclared here (not in a function) drm_drv.h:209: nonconstant array index in initializer drm_drv.h:209: (near initialization for `s3v_ioctls') drm_drv.h:209: `DRM_IOCTL_S3V_SIMPLE_LOCK' undeclared here (not in a function) drm_drv.h:209: nonconstant array index in initializer drm_drv.h:209: (near initialization for `s3v_ioctls') drm_drv.h:209: `DRM_IOCTL_S3V_SIMPLE_FLUSH_LOCK' undeclared here (not in a function) drm_drv.h:209: nonconstant array index in initializer drm_drv.h:209: (near initialization for `s3v_ioctls') drm_drv.h:209: `DRM_IOCTL_S3V_SIMPLE_UNLOCK' undeclared here (not in a function) drm_drv.h:209: nonconstant array index in initializer drm_drv.h:209: (near initialization for `s3v_ioctls') drm_drv.h:209: `DRM_IOCTL_S3V_STATUS' undeclared here (not in a function) drm_drv.h:209: nonconstant array index in initializer drm_drv.h:209: (near initialization for `s3v_ioctls') make: *** [s3v_drv.o] Error 1 Not sure all of what this means. GCC 2.95.2, glibc 2.2, kernel 2.4.16 David Bronaugh - End forwarded message - --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Failure to build the s3virge-0-0-1-branch
On Thu, Jun 27, 2002 at 12:48:30AM +0200, Massimiliano Lingua wrote: On Wed, 2002-06-26 at 19:16, Alan Hourihane wrote: It builds now, so could you 'cvs update' build, install, and check everything is working. I had some problem building it in mesa/src/drv/s3v In s3v_context.h (215) I have something like drm_s3v_sarea_t. Where other drivers seems to have now something like NAMESAREADRIPtr. I wonder: 1) is the former no longer valid? 2) am I supposed to add this new structure in some driver file? I fixed that a few hours ago. Ensure you do another 'cvs update' Alan. --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Capturing debugging info without networking
some of the current desktop managers has those dial home feature with the fault handler built in. each crash could get sent to the development team if the user likes it. Maybe improved crash logging should get an integral feature of X11 on general platforms (of course embedded folks wont like it). -Original Message- From: Sergey V. Udaltsov [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 21:23 To: Alexander Stohr Cc: Al Tobey; DRI Subject: RE: [Dri-devel] Capturing debugging info without networking Good boys! Can anyone invent the way to do the same thing with gdb? So on X crash one could get backtrace without remote debugging... Cheers, Sergey --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] How to trace switching to software rendering
On Wed, Jun 26, 2002 at 04:43:35PM -0600, Brian Paul wrote: Without looking at the code, my guess is that the GL_DECAL env mode with an RGBA texture probably isn't implemented in hardware. Hardware from that era often had limitations that prevented some combinations of texture env modes and texture formats from being done in hardware. There was a patch by Karl Lessard (?) that had something to do with GL_DECAL. What happened to it? -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: bsd-3-0-0-branch)
Log message: Include protection against ioctl() definition only in the __FreeBSD__ and XFree86Server case. These two drm.h's probably should be shared. With this commit radeon, r128, and mga are all working on FreeBSD and Linux. Haven't tested tdfx, but I have no reason to not expect it to work. At this point, who should review this for a merge? -- Eric Anholt [EMAIL PROTECTED] http://gladstone.uoregon.edu/~eanholt/dri/ --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: bsd-3-0-0-branch)
Eric Anholt wrote: Log message: The drmCommand interface was passing a size to DRM_IOR() and friends, when DRM_IOR was expecting a type, so on BSD only an int was copied in/out of the kernel. Make drmCommand use new DRM_IOC(), which expects a size. Good catch! I'm surprised this worked at all under Linux. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- 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] Re: [Dri-patches] CVS Update: xc (branch: bsd-3-0-0-branch)
Eric Anholt wrote: Log message: Include protection against ioctl() definition only in the __FreeBSD__ and XFree86Server case. These two drm.h's probably should be shared. With this commit radeon, r128, and mga are all working on FreeBSD and Linux. Haven't tested tdfx, but I have no reason to not expect it to work. At this point, who should review this for a merge? Damn, this is looking sweet! You have almost hit gold with this work, and here's what I would consider perfection: The source repository and plain source trees that haven't been built, yet would contain an os-support/linux/drm/kernel that contained the drm* files for Linux: drm_agpsupport.h drm_drawable.h drm_ioctl.h drm_os_freebsd.h drm_auth.hdrm_drv.h drm_linux.h drm_os_netbsd.h drm_bufs.hdrm_fops.h drm_lists.h drmP.h drm_context.h drm.h drm_lock.hdrm_scatter.h drm_dma.h drm_init.h drm_memory.h drm_sysctl.h drm_vm.h Not these are all Linux specific, but Hardware independent, and of course an os-support/bsd/drm/kernel and other os specific directories, too. None of which contained HW specific files. The os-support/shared/drm/kernel directory would then contain the HW specifics: gamma_dma.c i810_drv.h mga_drm.h r128_drm.h radeon_drv.h gamma_drm.h i810.h mga_drv.c r128_drv.c radeon_state.c gamma_drv.c i830_dma.c mga_drv.h r128_drv.h radeon.h gamma_drv.h i830_drm.h mga_state.c r128_state.c tdfx_drv.c gamma.h i830_drv.c mga_ucode.h r128.h tdfx.h i810_dma.c i830_drv.h mga_warp.c radeon_cp.c i810_drm.h i830.h mga.h radeon_drm.h i810_drv.c mga_dma.c r128_cce.c radeon_drv.c For the drivers you've ported to your OS independent templates (radeon, r128 and mga), it looks like the *_drv.c and Makefile support are all that's left in the OS directories. If you can get these out of there, even by adding a few OS ifdefs in the shared directory, you will get big leverage when a new driver is written. Generally, a driver writer copies another driver as a starting point, and they won't discard non development OS's simply because it's easier to ignore the directories. In other words, let's make new drivers work on all supported OS's by default instead of having to enable each OS/driver combo by hand. I can see the need for disabling a OS/driver combo by hand after we know it can't be easily supported. I'm definitely interested in hearing your opinion on squeeking out the last bigs of OS specifics in these drivers. I realize the last parts are usually the most difficult. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: bsd-3-0-0-branch)
On Wed, 2002-06-26 at 23:12, Jens Owen wrote: Eric Anholt wrote: Log message: The drmCommand interface was passing a size to DRM_IOR() and friends, when DRM_IOR was expecting a type, so on BSD only an int was copied in/out of the kernel. Make drmCommand use new DRM_IOC(), which expects a size. Good catch! I'm surprised this worked at all under Linux. Well, Linux (AFAIK) doesn't even care about the size passed in through ioctl, since our drivers in Linux try to copy in the actual size of the struct, not what the userland said the size was. On BSD the copyin is done by the ioctl syscall before passing the data to the per-ioctl handler. Really, the linux way is better for our code. I once poked at making the copyins work like linux, but it would have been ugly. -- Eric Anholt [EMAIL PROTECTED] http://gladstone.uoregon.edu/~eanholt/dri/ --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel