[Dri-devel] Mach64
Hi, I compiled yesterdays mach64-0-0-4 branch and did some tests with it. I configured 1024x768 screen resolution in XF86Config-4 and 16 bit depth. AGP Speed is 1 and DMA Buffers are 2 MB My machine is a Sony Vaio with 128 MB RAM, a 650 MHz P3 and an Ati Rage Mobility with 8 MB Ram. I got about 255 fps with glxgears. With ut I get the following fps rates: 640x480, 16 Bit World Texture Level: low Skin detail: low Show decals: yes dynamic lightning: yes about 25 fps 640x480, 15 Bit, World Texture: med Skin details: med Show decals: yes dynamic lightning: yes about 25 fps (but game stops from time to time for a second) 640x480, 15 Bit, World Texture: high Skin details: high Show decals: yes dynamic lightning: yes about 25 fps (but game stops often second) 800x600, 15 Bit, World Texture: low Skin details: low Show decals: yes dynamic lightning: yes about 18 fps 1024x768, 15 Bit, World Texture: low Skin details: low Show decals: yes dynamic lightning: yes about 12 fps Does it make a difference when I change resolution in XF86Config and not in UT? I will certainly try faster AGP transfer and bigger dma buffers. Attached is the X log. Greetings, Michael This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.1.99.1 (DRI mach64 branch) / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 20 August 2001 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/FAQ) Build Operating System: Linux 2.4.17 i686 [ELF] Module Loader present (==) Log file: /var/log/XFree86.0.log, Time: Tue Feb 19 12:22:12 2002 (==) Using config file: /etc/X11/XF86Config-4 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor Generic Monitor (**) | |--Device Generic Video Card (**) |--Input Device Generic Keyboard (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout de (**) XKB: layout: de (**) Option XkbVariant nodeadkeys (**) XKB: variant: nodeadkeys (==) Keyboard: CustomKeycode disabled (**) |--Input Device Configured Mouse (**) |--Input Device Generic Mouse (WW) The directory /usr/lib/X11/fonts/cyrillic does not exist. Entry deleted from font path. (**) FontPath set to unix/:7100,/usr/lib/X11/fonts/misc/:unscaled,/usr/lib/X11/fonts/100dpi/:unscaled,/usr/lib/X11/fonts/75dpi/:unscaled,/usr/lib/X11/fonts/misc/:unscaled,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi (==) RgbPath set to /usr/X11R6-DRI/lib/X11/rgb (==) ModulePath set to /usr/X11R6-DRI/lib/modules (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6-DRI/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.1.99.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6-DRI/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.1.99.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,7190 card 104d,806f rev 03 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,7191 card , rev 03 class 06,04,00 hdr 01 (II) PCI: 00:07:0: chip 8086,7110 card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:07:1: chip 8086,7111 card , rev 01 class 01,01,80 hdr 00 (II) PCI: 00:07:2: chip 8086,7112 card , rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:07:3: chip 8086,7113 card , rev 03 class 06,80,00 hdr 00 (II) PCI: 00:08:0: chip 104d,8039 card 104d,8071 rev 02 class 0c,00,10 hdr 00 (II) PCI: 00:09:0: chip 1073,0010 card 104d,8072 rev 02 class 04,01,00 hdr 00 (II) PCI: 00:0a:0: chip 14f1,2443 card 104d,8075 rev 01 class 07,80,00 hdr 00 (II) PCI: 00:0c:0: chip 1180,0478 card , rev 80 class
Re: [Dri-devel] ATI Radeon 7500 Performance Issues
Michel =?ISO-8859-1?Q?D=E4nzer?= writes:
On Thu, 2002-06-20 at 18:43, [EMAIL PROTECTED] wrote:
=?ISO-8859-1?Q?D=E4nzer?= writes:
ed, 2002-06-19 at 16:59, Adam K Kirchhoff wrote:
19 Jun 2002, Michel [ISO-8859-1] Dänzer wrote:
On Wed, 2002-06-19 at 16:29, Malverian ... wrote:
I'm having some pretty serious speed issues with my ATI Radeon 7500 64MB
DDR. And my hopes are in you guys for helping me iron out the kinks.
glxinfo says that direct rendering is enabled
X startup has no warnings or errors
I'm getting 500FPS in glxgears
That's exactly the speed I get on my XP 1800+ So we both must be
making the same mistake or something.
Make really sure you're using all the latest components.
Looking at the output of ldd on `which glxgear` and checking their
creation times showed that they are all what I'd expect. Also
/usr/X11R6/lib/modules/{dri|drivers|extensions} also have the creation
time I'd expect. Is there anything I should be looking for that I've
missed?
One thing I noticed is that I did not have EnablePageFlip set to true
in my X config file. Setting this raised the fps to 660. Is there any
reason why this isn't the default?
Also, 2D
clients will still have an impact on 3D performance, although it should
no longer be as bad as it used to be.
That was with 3 xterms (2 of which were doing nothing, one running
glxgears) xemacs with no files loaded. Window manager was afterstep.
So little 2D activity.
Anyhow, glxgears really isn't an important benchmark, how do 'real' apps
perform?
True, but it seems an easy way just to compare 'like' systems.
Now that I've enable the page flipping, 'Emilia pinball' is now
playable in a window size 1024x768 which it wasn't before.
bzflag plays well, but I haven't figure out yet how to make it give an
fps.
Crystal space's walktest instantly dies with a
walktest: t_imm_api.c:316: _tnl_end: Assertion `ctx-Driver.NeedFlush 0x1' failed.
It didn't used to before I used the TCL branch (now also main) branch.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Thanks,
Matt
---
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
[Dri-devel] Special Investor update. 3578NQFy6-335-12
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00D7_14C18B6A.B3286E66
Re: [Dri-devel] radeon drivers (tcl vs. non-tcl)
Zilvinas, Thanks for posting this data. It's nice to see confirmation of how things were intended to work. -- /\ 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: radeon cvs problem
Hi Michel! Saturday 22, at 02:48:06 PM you wrote: skip 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. Even more. _ALL_ binaries from dri.sf.net are broken :( But _after_ 11 jun. I have voodoo3 board and the same problems (sig11 after startup). After commenting out dri stuff, all works fine. My configuration: CPU: Cel400(4x100) MB: Abit BH6 (i440BX) RAM: 128 SDRAM Video: STB Voodoo3 3000 XFree86: 4.2.0 Kernel: 2.4.18 dri pkginfo: tdfx 3Dfx Banshee Voodoo 3/4/5 Driver 20020620 tdfx XFree86.0.log: XFree86 Version 4.2.0 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 11 March 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18-alt5-smp i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Sat Jun 22 18:42:11 2002 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout layout1 (**) |--Screen screen1 (0) (**) | |--Monitor PHILIPS 107P (**) | |--Device Voodoo3 (generic) (**) |--Input Device Mouse1 (**) |--Input Device Keyboard1 (**) Option AutoRepeat 250 30 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc101 (**) XKB: model: pc101 (**) Option XkbLayout ru (**) XKB: layout: ru (**) Option XkbOptions grp:ctrl_shift_toggle (**) XKB: options: grp:ctrl_shift_toggle (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:-1 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (**) Option AllowMouseOpenFail (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x8058, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,7190 card , rev 02 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,7191 card , rev 02 class 06,04,00 hdr 01 (II) PCI: 00:07:0: chip 8086,7110 card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:07:1: chip 8086,7111 card , rev 01 class 01,01,80 hdr 00 (II) PCI: 00:07:2: chip 8086,7112 card , rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:07:3: chip 8086,7113 card , rev 02 class 06,80,00 hdr 00 (II) PCI: 00:09:0: chip 10ec,8139 card 10ec,8139 rev 10 class 02,00,00 hdr 00 (II) PCI: 00:0d:0: chip 1000,0001 card 1000,1000 rev 23 class 01,00,00 hdr 00 (II) PCI: 01:00:0: chip 121a,0005 card 121a,003a rev 01 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) LoadModule: scanpci (II) Loading /usr/X11R6/lib/modules/libscanpci.a (II) Module scanpci: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) UnloadModule: scanpci (II) Unloading /usr/X11R6/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0x - 0x (0x0) MX[B] (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x88 (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0xd000 - 0xdfff (0x1000) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0xd000 - 0xd3ff (0x400) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0xd600 - 0xd7ff (0x200) MX[B] (II) Bus -1: bridge is at (0:7:0), (0,-1,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus -1 I/O range: (II) Bus -1 non-prefetchable memory
Re: [Dri-devel] radeon drivers (tcl vs. non-tcl)
On Saturday 22 June 2002 16:15, Jens Owen wrote: Zilvinas, Thanks for posting this data. It's nice to see confirmation of how things were intended to work. I'll second that. May I ask if Zilvinas could repeat with 60Hz? I know that this is a bad number but the RAMDAC clock has some influence. Most official benchmarks (Win) are made @60 Hz... Second: My dual Athlon MP 1900+ (MSI K7D Master-L, AMD 760MPX) with 512MB DDR-SDRAM (1 GB is comming soon) is up and running. I can get my hands on a Radeon 8500 and maybe a 7500, tomorrow or Monday. I'll do some viewperf-6.1.2 numbers on my V5 5500 @24 bit tonight. Mesa/demos ./gloss 596 frames in 5.006 seconds = 119.057 FPS -- cylinder 764 frames in 5.003 seconds = 152.708 FPS 760 frames in 5.006 seconds = 151.818 FPS 758 frames in 5.001 seconds = 151.57 FPS 483 frames in 5.004 seconds = 96.5228 FPS 420 frames in 5.003 seconds = 83.9496 FPS 420 frames in 5 seconds = 84 FPS 421 frames in 5.008 seconds = 84.0655 FPS -- teapot ipers is running @20-22 fps (~580.000 Poly/sec) Desktop resolution is 1280x1024@24 as always ;-) We need the Mesa (p)thread stuff badly 'cause all numbers are from single theard/process mode (the second CPU was all the time 100% idle). Cheers, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: [EMAIL PROTECTED] --- 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] How to trace switching to software rendering
Hi Paul,
thanks for your fast answer.
Am Sam, 2002-06-22 um 00.00 schrieb Brian Paul:
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.
Sounds easy :)
But now I have another small problem...
Before doing any changes to the dri sources I did a make world on the
freshly checked out sources. After copying mga_dri to the right place
and restarting X I always get a seg fault after:
(II) MGA(0): [drm] bpp: 16 depth: 16
(II) MGA(0): [drm] Sarea 2200+664: 2864
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
strace says:
1131 geteuid32() = 0
1131 write(0, drmOpenDevice: minor is 0\n, 26) = 26
1131 stat64(/dev/dri, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
1131 chown32(0x848b2d4, 0, 0) = 0
1131 chmod(/dev/dri, 0777) = 0
1131 write(0, drmOpenDevice: node name is /dev..., 43) = 43
1131 stat64(/dev/dri/card0, {st_mode=S_IFCHR|0666,
st_rdev=makedev(226, 0), ...}) = 0
1131 chown32(0xb844, 0, 0) = 0
1131 chmod(/dev/dri/card0, 0666) = 0
1131 open(/dev/dri/card0, O_RDWR)= 6
1131 write(0, drmOpenDevice: open result is 6,..., 38) = 38
1131 ioctl(6, DEVFSDIOC_GET_PROTO_REV, 0x83d2ae8) = 0
1131 ioctl(6, DEVFSDIOC_GET_PROTO_REV, 0x83d2ae8) = 0
1131 --- SIGSEGV (Segmentation fault) ---
I'm using the XFree 4.2 Debian packages for Brandon. A test with
mga-20020622-linux.i386.tar.bz2 from http://dri.sourceforge.net/ had the
same result as with the XServer from extras.tgz.
So I've to do some printf into os-support/linux/drm/xf86drm.c to find
that problem first (or is that a known issure?).
Bye, Michael
---
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] merge with Gatos
Am Fre, 2002-06-21 um 22.37 schrieb Sergey V. Udaltsov: I recently asked the question about merging Mach64 DRI with Gatos project - and got no answer. So, now I am trying to use xine - and found that mach64 dri snapshots do not properly support XVideo extension (at least in YUV overlay area). So could please anyone tell me what are perspectives of this merge? I realize it is the lowest priority issue but I hope it is not that difficult - now when 2D acceleration is already somehow enabled in DRI driver... Same for Radeon 8500, the XF4.2 and DRI CVS snapshots hat non-working XVideo support (black boxes on top of everything else, not clipped and some pixels too far on the right). The drivers from gatos are working. they are using DRI for the xv support and also have modified kernel drm drivers - but it's working fine. --- 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] x freezes
On Thu, 2002-06-20 at 22:19, Zilvinas Valinskas wrote: On Thu, Jun 20, 2002 at 09:24:21PM -0700, Bret Towe wrote: i dont know if anyone else is getting this problem but after exiting and loading x a couple times and using gl once in a while when reloading x for the 3-5th time sometimes first time it will start loading and the monitor never comes out of standby mode and the computer is frozen hard i have to hit reset i have this trouble in both tcl and main trunk currently not having the drm module loaded seems to stop this problem my comp is a athlon 850 with a radeon 7500 What kind of MB is it ? What is MB chipset ? Are you overclocking CPU ? What is kernel version :) and xfree version ? im not 100% sure what MB it is and i misplaced the manual the chipset is amd viper/irongate (least i think thats what u need to know) no overclocking kernel is 2.4.18 + preempt patch (stable as a rock it seems) xfree is 4.2.0 then dri cvs trunk installed over the top and the drm is from cvs Right now here for the last couple hours I was starting/stopping Xserver, changing drivers and so on ... No lockup it is stable. I am using the latest and the greatest driver ;) version from CVS. -- Zilvinas Valinskas --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- 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] How to trace switching to software rendering
Michael Schlueter wrote:
Hi Paul,
His first name is Brian :-)
thanks for your fast answer.
Am Sam, 2002-06-22 um 00.00 schrieb Brian Paul:
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.
Sounds easy :)
But now I have another small problem...
Before doing any changes to the dri sources I did a make world on the
freshly checked out sources. After copying mga_dri to the right place
and restarting X I always get a seg fault after:
(II) MGA(0): [drm] bpp: 16 depth: 16
(II) MGA(0): [drm] Sarea 2200+664: 2864
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
strace says:
1131 geteuid32() = 0
1131 write(0, drmOpenDevice: minor is 0\n, 26) = 26
1131 stat64(/dev/dri, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
1131 chown32(0x848b2d4, 0, 0) = 0
1131 chmod(/dev/dri, 0777) = 0
1131 write(0, drmOpenDevice: node name is /dev..., 43) = 43
1131 stat64(/dev/dri/card0, {st_mode=S_IFCHR|0666,
st_rdev=makedev(226, 0), ...}) = 0
1131 chown32(0xb844, 0, 0) = 0
1131 chmod(/dev/dri/card0, 0666) = 0
1131 open(/dev/dri/card0, O_RDWR)= 6
1131 write(0, drmOpenDevice: open result is 6,..., 38) = 38
1131 ioctl(6, DEVFSDIOC_GET_PROTO_REV, 0x83d2ae8) = 0
1131 ioctl(6, DEVFSDIOC_GET_PROTO_REV, 0x83d2ae8) = 0
1131 --- SIGSEGV (Segmentation fault) ---
I'm using the XFree 4.2 Debian packages for Brandon. A test with
mga-20020622-linux.i386.tar.bz2 from http://dri.sourceforge.net/ had the
same result as with the XServer from extras.tgz.
So I've to do some printf into os-support/linux/drm/xf86drm.c to find
that problem first (or is that a known issure?).
Make sure your DRM driver is recompiled for your kernel. Best to use
the DRM driver in the DRI source tree. cd to
xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and make
-f Makefile.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] 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
[Dri-devel] radeon-20020621 install problem
Hoping I get a driver that works with my all-in-wonder 7500 card, I downloaded radeon-20020621-linux.i386.tar but running ./install.sh exited with an error; dri.log is included at the end of my message. My system: # cat /etc/redhat-release Red Hat Linux release 7.3 (Valhalla) # rpm -q XFree86 kernel XFree86-4.2.0-8 kernel-2.4.18-5 Thx for any help; please note that I set the reply-to to [EMAIL PROTECTED] since I am not subscribed, Mate -- --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis cc -O2 -Wall -Wwrite-strings -Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs -Wpointer-arith -D__KERNEL__ -DMODULE -fomit-frame-pointer -DEXPORT_SYMTAB -I0 -c radeon_drv.c -o radeon_drv.o In file included from /usr/include/linux/module.h:20, from drmP.h:43, from radeon_drv.c:32: /usr/include/linux/modversions.h:1:2: #error Modules should never use kernel-headers system headers, /usr/include/linux/modversions.h:2:2: #error but rather headers from an appropriate kernel-source package. /usr/include/linux/modversions.h:3:2: #error Change -I/usr/src/linux/include (or similar) to /usr/include/linux/modversions.h:4:2: #error -I/lib/modules/$(uname -r)/build/include /usr/include/linux/modversions.h:5:2: #error to build against the currently-running kernel. In file included from /usr/include/linux/timex.h:152, from /usr/include/linux/sched.h:14, from /usr/include/linux/mm.h:4, from /usr/include/linux/locks.h:5, from /usr/include/linux/devfs_fs_kernel.h:6, from /usr/include/linux/miscdevice.h:4, from drmP.h:45, from radeon_drv.c:32: /usr/include/asm/timex.h:10:21: asm/msr.h: No such file or directory In file included from /usr/include/linux/pagemap.h:15, from /usr/include/linux/locks.h:8, from /usr/include/linux/devfs_fs_kernel.h:6, from /usr/include/linux/miscdevice.h:4, from drmP.h:45, from radeon_drv.c:32: /usr/include/asm/pgtable.h:17:24: asm/fixmap.h: No such file or directory In file included from /usr/include/linux/highmem.h:5, from /usr/include/linux/pagemap.h:16, from /usr/include/linux/locks.h:8, from /usr/include/linux/devfs_fs_kernel.h:6, from /usr/include/linux/miscdevice.h:4, from drmP.h:45, from radeon_drv.c:32: /usr/include/asm/pgalloc.h:6:24: asm/fixmap.h: No such file or directory In file included from radeon_drv.c:32: drmP.h:61:25: asm/uaccess.h: No such file or directory In file included from drm_dma.h:35, from radeon_drv.c:85: /usr/include/linux/interrupt.h:44:25: asm/hardirq.h: No such file or directory /usr/include/linux/interrupt.h:45:25: asm/softirq.h: No such file or directory make: *** [radeon_drv.o] Error 1 --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon driver problem ... X dont satart!
Hi everybody!! maybe this is not the right question for this list but ... well here goes: I was using the radeon driver wich came with this package radeon-20020525-linux.i386.tar.bz2, it was working right ... well not too much right, just 400FPS on glxgears when some peple say they get 1000FPS and more, well it was working for me anyway and I have to thank your for the great job you ar doing ... well the thing is I've updated to radeon-20020621-linux.i386.tar.bz2 and X cant start, everything goes right until well, the last lines of the log hehe :P well these are some outputs: dmesg | grep agp: agpgart: Maximum main memory to use for agp memory: 203M agpgart: Detected Via Apollo Pro KT266 chipset agpgart: AGP aperture is 64M @ 0xf800 dmesg | grep drm: [drm] AGP 0.99 on VIA Apollo KT133 @ 0xf800 64MB [drm] Initialized radeon 1.3.1 20020611 on minor 0 tail Xfree.icantrememberwhat.log: (==) RADEON(0): Write-combining range (0xf000,0x400) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) Fatal server error: Caught signal 11. Server aborting does anybody know what can it be?? THANKS TO ALL OF YOU!!!, there is people at the end of the world who like what you are doing! if you look for Punta Arenas, Chile, my city you will see :) Bye! thork --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] website.
Hey. I want to get started putting up the new site, but no-one has told me how to access the webspace... I've given my sourceforge details and been added to the project... --- 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] website.
Ian Molton wrote: Hey. I want to get started putting up the new site, but no-one has told me how to access the webspace... I've given my sourceforge details and been added to the project... Ian, I can't help you with access details, but I'd like you to stage this below the current main site until we've all had a chance to look at the new format and get familiar with it. I use the current site quite a bit, and this would ease any transition for me. Thanks, 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
Re: [Dri-devel] How to trace switching to software rendering
Am Sam, 2002-06-22 um 20.45 schrieb Jens Owen: Michael Schlueter wrote: Hi Paul, His first name is Brian :-) Ups, sorry for that. So I've to do some printf into os-support/linux/drm/xf86drm.c to find that problem first (or is that a known issure?). Make sure your DRM driver is recompiled for your kernel. Best to use the DRM driver in the DRI source tree. cd to xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and make -f Makefile.linux yes, I did that and the install script of the precompiled did that also. After inclunding a few printf into xc/programs/Xserver/hw/xfree86/os-support/linux/drmxf86drm.c and then including a few more lines it crashed on a different spot. So I think there is some wrong with my system and I have to take a deeper look into it. Bye, Michael --- 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 drivers (tcl vs. non-tcl)
On Sat, Jun 22, 2002 at 08:15:30AM -0600, Jens Owen wrote: Zilvinas, Thanks for posting this data. It's nice to see confirmation of how things were intended to work. No problem Jens :)) I am glad you have found those results usefull ;) -- /\ 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 -- Zilvinas Valinskas --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
