[Dri-devel] [jkay@cox.net: Re: [Dri-users] Ann: gcc-2.96 compiled snapshots available]
- Forwarded message from John Kelly [EMAIL PROTECTED] - Date: 28 Sep 2002 23:34:22 -0400 From: John Kelly [EMAIL PROTECTED] Subject: Re: [Dri-users] Ann: gcc-2.96 compiled snapshots available To: José Fonseca [EMAIL PROTECTED] On Sat, 2002-09-28 at 13:02, José Fonseca wrote: I just uploaded a set of binary snapshots built from the CVS head using RedHat's compat-gcc-7.3-2.96.110 package (which produces code compatible with the gcc bundled with the RedHat 7.3 and is the same which was producing the snapshots before). This archive installed perfectly, but it still causes XFree to exit with error 11, and the monitor goes into sleep mode instead of showing the GDM login. Reverting manually back to Sept 21 r200 fixes all. - End forwarded message - --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] S3 Texture Compression...
Hi all. I'm a proud Radeon owner with an Gentoo-1.4 / Unreal Tournament 2003 Demo CD. I also have a Geforce 2 MX 400 (my brother's but he gave it to me when he sold the rest of his computer) and I've confirmed that UT runs GREAT on it. Anyway, I understand that S3 have been approached a few times regarding their patented S3 Texture Compression. I expect there's about 1% chance they will give the DRI team the OK to go ahead with implementing their Texture Compression (their patents are all they have). Now unfortunately I have a 'classic' radeon (64MB DDR VIVO) which (I assume) is unsupported by ATI's closed-source binaries, so their drivers aren't an option. So instead I would hope that ATI (or possibly S3) would provide a closed-source binary module to add S3 Texture Compression to the Radeon / all DRI drivers. Is this possible? (ie the DRI Radeon module with a supporting S3 Texture Compression module)? While I'm at it, I read that some Gatos stuff has been merged recently, but I haven't been able to get TV-out running (I used to have it working under XFree86-4.1.0 / Gatos, but it was a little crashy and WineX doesn't work so well with it). So is the TV-out stuff not merged? Thanks is advance! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Texture Compression...
On Son, 2002-09-29 at 12:00, Ayahuasca wrote: While I'm at it, I read that some Gatos stuff has been merged recently, Where have you read that? but I haven't been able to get TV-out running (I used to have it working under XFree86-4.1.0 / Gatos, but it was a little crashy and WineX doesn't work so well with it). So is the TV-out stuff not merged? No, I haven't merged any GATOS code but merely XVideo fixes from XFree86 CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] R128 Problems
The latest snapshot does not report DRI in use by glxinfo and glxgears confirms this. An older snapshot 18092002 does work for these glx tests. However, using this older snapshot with mplayer or xine either hangs my machine, usually after corrupting the screen or trashes the window of the program using it. I'm using a DELL Inspiron 4000 with R128 M3 on RH 7.3, kernel 2.4.19. If anyone can suggest additional tests or information I can provide, please e-mail me at [EMAIL PROTECTED] and I will do my best to provide. Thanks. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [patch] smart irq/busy wait in radeonWaitForFrameCompletion
Keith, I implemented the smart waiting scheme we discussed yesterday. Just to get the purpose of the whole thing straight again: it is to minimize the amount of busy waiting as well as the number of lost IRQs. In that case the attached patch does a pretty good job. The simple cases are when either the CPU clearly outpaces the GPU or vice versa. The worst case is if they run at about the same pace. Then small load changes lead to a lost IRQ or a couple of busy cycles each time the waiting scheme is switched. For this to work I had to got back to real busy waiting since usleep is just too slow. On my system usleep(1) takes quite exactly 20 ms. This lead to the following scenario for applications with framerates above 100: - render frame 1 - swap/flip (no waiting, no IRQ emitted) - render frame 2 - swap/flip (wait and emit IRQ) Both frames are completed by the time usleep returns and everything starts from the beginning. So all IRQs are lost and the frame rate is throttled to 100 fps. The new version uses usleep only if RADEON_NO_IRQS is set and RADEON_NO_USLEEPS is not set. Best regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! radeon_smartwait.patch Description: Binary data
Re: [Dri-devel] [jkay@cox.net: Re: [Dri-users] Ann: gcc-2.96compiled snapshots available]
On Son, 2002-09-29 at 11:02, José Fonseca wrote: - Forwarded message from John Kelly [EMAIL PROTECTED] - [...] On Sat, 2002-09-28 at 13:02, José Fonseca wrote: I just uploaded a set of binary snapshots built from the CVS head using RedHat's compat-gcc-7.3-2.96.110 package (which produces code compatible with the gcc bundled with the RedHat 7.3 and is the same which was producing the snapshots before). This archive installed perfectly, but it still causes XFree to exit with error 11, and the monitor goes into sleep mode instead of showing the GDM login. Well, I just made the ultimate test for the XAA versioning: copied libxaa.a from the Debian 4.2.1 installation into my DRI tree and fired it up. Worked as expected, the radeon driver detected the old XAA and didn't use TwoPoint line acceleration. So there must be another problem... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: XAA versioning?
On Son, 2002-09-29 at 04:47, Chad Page wrote: I did my own build from CVS and copied libxaa.a from it into the modules directory - 2D and 3D work with one head but I still get signal 11 with two heads, with and without xinerama. I can disable acceleration and it will work, so there seems to be another xaa problem with shared entities. Can you try to track down where the segfault occurs? Kevin, I assume you've tested the acceleration updates with multihead? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R128 Problems
On Son, 2002-09-29 at 15:51, Jay Phelps wrote: The latest snapshot does not report DRI in use by glxinfo and glxgears confirms this. An older snapshot 18092002 does work for these glx tests. Is direct rendering reported as enabled in the server log with a current snapshot? If not, does it tell a reason? However, using this older snapshot with mplayer or xine either hangs my machine, usually after corrupting the screen or trashes the window of the program using it. Probably related to DMA transfers for Xv. XFree86 CVS has that disabled by default, maybe I should merge that one of these days. I think someone reported Option XAANoPixmapCache (or another pixmap related option) works around the problem. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: gcc-2.96 compiled snapshots available
On 29 Sep 2002 01:58:16 +0200 Michel Dänzer [EMAIL PROTECTED] wrote: On Sam, 2002-09-28 at 19:59, Felix Kühling wrote: On Sat, 28 Sep 2002 18:02:08 +0100 José Fonseca [EMAIL PROTECTED] wrote: I just uploaded a set of binary snapshots built from the CVS head using RedHat's compat-gcc-7.3-2.96.110 package (which produces code compatible with the gcc bundled with the RedHat 7.3 and is the same which was producing the snapshots before). Thanks José! The files are the *-linux-gcc296.i386.tar.bz2 available from http://dri.sourceforge.net/snapshots/ . In case your web browser gives you a hard time to distinguish they are half size of the ones generated by gcc-3.2 (!) as someone already had notice. I have no idea why is that. As of gcc-3.1 the default debug info format has changed to dwarf-2. Maybe that's at least part of the problem. All of you which have been experiencing problems with the latest snapshots please test and report back to the dri-devel mailing list. If there is a difference then I'll make them available on a regular basis. I don't use binary snapshots. But I am compiling DRI with gcc-3.2 since yesterday myself. There are problems with the radeon driver which I didn't have with gcc-2.95.4, though it never crashes my machine. What problems then? They disappeared ... probably after a recent cvs update. It was that the glxgears window went black when I moved it around. Moving it a bit more brought the gears back sometimes. Opaque moving made them flicker. There were more problems with other apps. Some xscreensaver hacks just showed a black window. Now they work all right. Felix P.S. I wrote about the same reply before, but it didn't get sent, I think (managed to crash my machine, old problem). If you get this twice, ignore one of them ;) __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Texture Compression...
Ayahuasca wrote: Hi all. I'm a proud Radeon owner with an Gentoo-1.4 / Unreal Tournament 2003 Demo CD. I also have a Geforce 2 MX 400 (my brother's but he gave it to me when he sold the rest of his computer) and I've confirmed that UT runs GREAT on it. Anyway, I understand that S3 have been approached a few times regarding their patented S3 Texture Compression. I expect there's about 1% chance they will give the DRI team the OK to go ahead with implementing their Texture Compression (their patents are all they have). Now unfortunately I have a 'classic' radeon (64MB DDR VIVO) which (I assume) is unsupported by ATI's closed-source binaries, so their drivers aren't an option. Hopefully, S3 is more concerned about licensing to the hardware manufacturers than driver vendors. In the DRI drivers, using a compressed textures will be little more than specifying a new register value to indicate the compressed format. In software, it's just an implementation of the algorithm spelt out in the OpenGL extension specification. It's hardly a secret technique. So instead I would hope that ATI (or possibly S3) would provide a closed-source binary module to add S3 Texture Compression to the Radeon / all DRI drivers. Is this possible? (ie the DRI Radeon module with a supporting S3 Texture Compression module)? A binary module could be done in principle, but supporting binary modules is a real chore. And since the algorithms are public, anyone could go and re-implement the binary module. So, it would be kind of pointless. -Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Texture Compression...
Alle 17:32, domenica 29 settembre 2002, Brian Paul ha scritto: So instead I would hope that ATI (or possibly S3) would provide a closed-source binary module to add S3 Texture Compression to the Radeon / all DRI drivers. Is this possible? (ie the DRI Radeon module with a supporting S3 Texture Compression module)? A binary module could be done in principle, but supporting binary modules is a real chore. And since the algorithms are public, anyone could go and re-implement the binary module. So, it would be kind of pointless. -Brian To summarize: - I bought a graphics card, with drivers from the vendor that I don't need. - Those drivers have support for the 'clever' texture compression format. - My vendor already paid for the implementation of the patented technology in my graphic card. Still, implementing an open driver, for it would be 'illegal'? Leaving aside the software patent part of the whole problem, surely implementing the extension for boards with hardware implementation of it should be ok, isn't it? Luciano -- Luciano Montanaro// Public GPG Key at wwwkeys.pgp.net /\ ASCII RIBBON \X/ [EMAIL PROTECTED] \ / CAMPAIGN X AGAINST HTML / \ MAIL --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Texture Compression...
On Sun, 2002-09-29 at 17:04, Luciano Montanaro wrote: To summarize: - I bought a graphics card, with drivers from the vendor that I don't need. - Those drivers have support for the 'clever' texture compression format. - My vendor already paid for the implementation of the patented technology in my graphic card. Still, implementing an open driver, for it would be 'illegal'? Leaving aside the software patent part of the whole problem, surely implementing the extension for boards with hardware implementation of it should be ok, isn't it? It depends. It depends on the country, in the USA it depends on the interpretation of the laws on sale of goods for example. Also annoying S3 isn't neccessarily useful. Taiwanese vendors are slow to most things in my experience so giving them a bit of time to do their thinking, to work out that the base Mesa supporting S3TC only helps them sell the licenses to more hardware vendors and so forth as XFree are doing is (although infuriatingly slow) the right thing. Not everyone moves at the speed of open source. Alan --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website - archives
otherwise alphbetically eg Manufacturers Distros (I'll fix distro's now) Then you only have to fix status.phtml (Supported Cards) to make it equally to links.phtml (Graphics Card Manufacturers). Well spotted, I'll make the status.phtml alphabetical. cheers Liam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: XAA versioning?
On 29 Sep 2002, Michel [ISO-8859-1] Dänzer wrote: On Son, 2002-09-29 at 04:47, Chad Page wrote: I did my own build from CVS and copied libxaa.a from it into the modules directory - 2D and 3D work with one head but I still get signal 11 with two heads, with and without xinerama. I can disable acceleration and it will work, so there seems to be another xaa problem with shared entities. Can you try to track down where the segfault occurs? I enabled debugging mode (after commenting out some bad variable references in some radeon_trace statements, and adding radeon_version.h to radeon_cursor.c) and it sig11's right after the cursor is initialized and before any acceleration setup is done on screen 1 - this is a red herring as it crashes without hardware cursor enabled. - Chad Kevin, I assume you've tested the acceleration updates with multihead? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] ATI Radeon VE QY (AGP) new drivers (personal) problems
Hi! here is my problem: I was using the drm drivers wich comes with the 2.4.19 kernel (1.1.1), it was workig right exept fo this: (II) RADEON(0): Using 8 MB AGP aperture it looks like it is only using 8Mb and my has 64Mb (glxgear only gives 480FPS). The real problem started when I updated yesterday, when I xinit the screen gets black and when I ctrl+alt+F* the screen keeps black, but when I ctrl+alt+supr the system reboots, the system is working but the video card looks shuted down. mysystem: linux2.4.19, XFree86 4.2.1, AMD Athlon XP 1600+, Asus A7v266-e mb, and of course ati radeon 7000 with 64 mb of memory. tanks for your help. Esteban Fuentes. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: XAA versioning?
On 29 Sep 2002, Michel [ISO-8859-1] Dänzer wrote: On Son, 2002-09-29 at 04:47, Chad Page wrote: I did my own build from CVS and copied libxaa.a from it into the modules directory - 2D and 3D work with one head but I still get signal 11 with two heads, with and without xinerama. I can disable acceleration and it will work, so there seems to be another xaa problem with shared entities. Can you try to track down where the segfault occurs? I tracked it down to radeon_video.c in RadeonResetVideo - the info-accel-sync(pScrn) call causes the sig 11, which would imply that the structure hadn't been fully initialized when called. With that line commented out it works ok, but there's probably a different root cause. - Chad --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] RE: R128 Problems - The information you requested
It looks to me like DRI claims to be starting up A-OK. However, glxinfo reports no and gears FPS is as such that it's certainly not using DRI, I'm including my log file for examination. XFree86 Version 4.2.0 (Red Hat Linux release: 4.2.0-8) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 23 January 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.17-0.13smp i686 [ELF] Build Host: daffy.perf.redhat.com 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: Sun Sep 29 14:47:46 2002 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout Anaconda Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device ATI Rage 128 Mobility (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7100 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/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/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 = 0x8000183c, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,7190 card , 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:03:0: chip 104c,ac51 card 4000, rev 00 class 06,07,00 hdr 82 (II) PCI: 00:03:1: chip 104c,ac51 card 4800, rev 00 class 06,07,00 hdr 82 (II) PCI: 00:07:0: chip 8086,7110 card , rev 02 class 06,80,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 125d,1998 card 1028,00b0 rev 10 class 04,01,00 hdr 00 (II) PCI: 00:10:0: chip 10b7,6055 card 10b7,6456 rev 10 class 02,00,00 hdr 80 (II) PCI: 00:10:1: chip 10b7,1007 card 10b7,615b rev 10 class 07,80,00 hdr 00 (II) PCI: 01:00:0: chip 1002,4c46 card 1028,00b0 rev 02 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-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: 0x8c (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0xe000 - 0xe0ff (0x100) IX[B] [1] -1 0xe400 - 0xe4ff (0x100) IX[B] [2] -1 0xe800 - 0xe8ff (0x100) IX[B] [3] -1 0xec00 - 0xecff (0x100) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0xfd00 - 0xfeff (0x200) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0xf800 - 0xfbff (0x400) MX[B] (--) PCI:*(1:0:0) ATI Rage 128 Mobility LF rev 2, Mem @ 0xf800/26, 0xfdffc000/14, I/O @ 0xec00/8 (II) Addressable bus resource ranges are [0] -1 0x - 0x (0x0) MX[B] [1] -1 0x - 0x (0x1) IX[B] (II) OS-reported resource ranges: [0] -1 0xffe0 - 0x (0x20) MX[B](B) [1] -1
[Dri-devel] radeon problems
Hi. Is there any known bug in the radeon driver? the 0929 snapshot doesnt work for me. it segfaults when I start X. I have pageflip and fast writes enables, as well as AGP4x. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon problems
Am Sonntag, 29. September 2002 22:34 schrieb Ian Molton: Hi. Is there any known bug in the radeon driver? the 0929 snapshot doesnt work for me. it segfaults when I start X. I have pageflip and fast writes enables, as well as AGP4x. Radeon 7xxx or 8xxx (r100/r200)? A little bit more specific would be cool ;-) I didn't had any of all the reported trouble for the last several weeks (r200-branch and trunk) even after the Xv/libxaa merge. With both options (AGPMode 4, AGPFastWrite 1, EnablePageflip). Regards, Dieter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] knobs to turn?
Hi, I was wondering if some dev out there could spend say 2-5 minutes and post an email that lists all of the possible knobs that can be turned. I know there's a bunch, but they're scattered though several postings and hard to find. For example: ENV VARS LIBGL_DEBUG # enable debugging XF86Config == Option AGPMode [1|2|4]# ... Option AGPFastWrite [1|false] # ... I keep seeing posts about pageflipping, hw perf boxes, and many other little things to try and get a little frustrated trying to track down the knob to turn them on/off... This could make a good little web page addition to the site as well. thx, Nick --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Sun, 29 Sep 2002 22:47:47 +0200 Felix Kühling [EMAIL PROTECTED] wrote: On Sun, 29 Sep 2002 13:22:44 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: CVSROOT:/cvsroot/dri Module name:xc Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ Changes by: keithw@usw-pr-cvs1. 02/09/29 13:22:44 Log message: irqwait patch from felix Modified files: xc/xc/lib/GL/mesa/src/drv/radeon/: radeon_context.c radeon_context.h radeon_ioctl.c Revision ChangesPath 1.19 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c 1.15 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.h 1.27 +54 -49xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c Thanks for applying. However, this was yesterday's patch ;-). Just cvs updated my tree and made a patch of my NEW waiting code against the latest trunk. See [patch] smart irq/busy wait in radeonWaitForFrameCompletion on dri-devel. I just realized that I forgot to include radeon_context.[ch] in the patch posted with that mail. :-| This one is complete. Oops, forgot one debug message. Could you remove fprintf (stderr, Waited %d.\r, wait); from radeon_ioctl.c line 692 manually? I don't want to spam the list with patches. Thanks, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Sun, 29 Sep 2002 13:22:44 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ Changes by: keithw@usw-pr-cvs1. 02/09/29 13:22:44 Log message: irqwait patch from felix Modified files: xc/xc/lib/GL/mesa/src/drv/radeon/: radeon_context.c radeon_context.h radeon_ioctl.c Revision ChangesPath 1.19 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c 1.15 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.h 1.27 +54 -49xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c Thanks for applying. However, this was yesterday's patch ;-). Just cvs updated my tree and made a patch of my NEW waiting code against the latest trunk. See [patch] smart irq/busy wait in radeonWaitForFrameCompletion on dri-devel. I just realized that I forgot to include radeon_context.[ch] in the patch posted with that mail. :-| This one is complete. Best regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! radeon_smartwait.patch Description: Binary data
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Sonntag, 29. September 2002 22:57 schrieb Felix Kühling: On Sun, 29 Sep 2002 22:47:47 +0200 Felix Kühling [EMAIL PROTECTED] wrote: On Sun, 29 Sep 2002 13:22:44 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ Changes by: keithw@usw-pr-cvs1. 02/09/29 13:22:44 Log message: irqwait patch from felix Modified files: xc/xc/lib/GL/mesa/src/drv/radeon/: radeon_context.c radeon_context.h radeon_ioctl.c Revision ChangesPath 1.19 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c 1.15 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.h 1.27 +54 -49xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c Thanks for applying. However, this was yesterday's patch ;-). Just cvs updated my tree and made a patch of my NEW waiting code against the latest trunk. See [patch] smart irq/busy wait in radeonWaitForFrameCompletion on dri-devel. I just realized that I forgot to include radeon_context.[ch] in the patch posted with that mail. :-| This one is complete. Oops, forgot one debug message. Could you remove fprintf (stderr, Waited %d.\r, wait); from radeon_ioctl.c line 692 manually? I don't want to spam the list with patches. Is r100/r200 a completely different thing? If not why not a patch against both? Then the testing audience should be much wider. Thanks, Dieter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon problems
On Sun, 29 Sep 2002 22:52:57 +0200 Dieter Nützel [EMAIL PROTECTED] wrote: Am Sonntag, 29. September 2002 22:34 schrieb Ian Molton: Hi. Is there any known bug in the radeon driver? the 0929 snapshot doesnt work for me. it segfaults when I start X. I have pageflip and fast writes enables, as well as AGP4x. Radeon 7xxx or 8xxx (r100/r200)? A little bit more specific would be cool ;-) Sorry. slaps wrist Its a 7500. I didn't had any of all the reported trouble for the last several weeks (r200-branch and trunk) even after the Xv/libxaa merge. With both options (AGPMode 4, AGPFastWrite 1, EnablePageflip). Uh-oh... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Sun, 29 Sep 2002 23:25:03 +0200 Dieter Nützel [EMAIL PROTECTED] wrote: Am Sonntag, 29. September 2002 22:57 schrieb Felix Kühling: On Sun, 29 Sep 2002 22:47:47 +0200 Felix Kühling [EMAIL PROTECTED] wrote: On Sun, 29 Sep 2002 13:22:44 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: CVSROOT:/cvsroot/dri Module name:xc Repository: xc/xc/lib/GL/mesa/src/drv/radeon/ Changes by: keithw@usw-pr-cvs1. 02/09/29 13:22:44 Log message: irqwait patch from felix Modified files: xc/xc/lib/GL/mesa/src/drv/radeon/: radeon_context.c radeon_context.h radeon_ioctl.c Revision ChangesPath 1.19 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c 1.15 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.h 1.27 +54 -49xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c Thanks for applying. However, this was yesterday's patch ;-). Just cvs updated my tree and made a patch of my NEW waiting code against the latest trunk. See [patch] smart irq/busy wait in radeonWaitForFrameCompletion on dri-devel. I just realized that I forgot to include radeon_context.[ch] in the patch posted with that mail. :-| This one is complete. Oops, forgot one debug message. Could you remove fprintf (stderr, Waited %d.\r, wait); from radeon_ioctl.c line 692 manually? I don't want to spam the list with patches. Is r100/r200 a completely different thing? If not why not a patch against both? Then the testing audience should be much wider. Sure. As far as I could see the code is very similar. However, this: rmesa-do_irqs = (0 rmesa-dri.drmMinor = 6 !getenv(R200_NO_IRQS) rmesa-r200Screen-irq); looks like IRQs are turned off by default on R200. So my code wouldn't be used. Is the reason for IRQs being disabled that the frame throttling is not implemented properly or are there lower level problems with IRQs? Thanks, Dieter Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Felix Kühling wrote: On Sun, 29 Sep 2002 23:25:03 +0200 Dieter Nützel [EMAIL PROTECTED] wrote: Am Sonntag, 29. September 2002 22:57 schrieb Felix Kühling: On Sun, 29 Sep 2002 22:47:47 +0200 Felix Kühling [EMAIL PROTECTED] wrote: On Sun, 29 Sep 2002 13:22:44 -0700 Keith Whitwell [EMAIL PROTECTED] wrote: CVSROOT: /cvsroot/dri Module name: xc Repository:xc/xc/lib/GL/mesa/src/drv/radeon/ Changes by:keithw@usw-pr-cvs1. 02/09/29 13:22:44 Log message: irqwait patch from felix Modified files: xc/xc/lib/GL/mesa/src/drv/radeon/: radeon_context.c radeon_context.h radeon_ioctl.c Revision ChangesPath 1.19 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c 1.15 +1 -0 xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.h 1.27 +54 -49xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c Thanks for applying. However, this was yesterday's patch ;-). Just cvs updated my tree and made a patch of my NEW waiting code against the latest trunk. See [patch] smart irq/busy wait in radeonWaitForFrameCompletion on dri-devel. I just realized that I forgot to include radeon_context.[ch] in the patch posted with that mail. :-| This one is complete. Oops, forgot one debug message. Could you remove fprintf (stderr, Waited %d.\r, wait); from radeon_ioctl.c line 692 manually? I don't want to spam the list with patches. Is r100/r200 a completely different thing? If not why not a patch against both? Then the testing audience should be much wider. Sure. As far as I could see the code is very similar. However, this: rmesa-do_irqs = (0 rmesa-dri.drmMinor = 6 !getenv(R200_NO_IRQS) rmesa-r200Screen-irq); looks like IRQs are turned off by default on R200. So my code wouldn't be used. Is the reason for IRQs being disabled that the frame throttling is not implemented properly or are there lower level problems with IRQs? No, this is a hangover from the bugs last week. It can be removed now. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] knobs to turn?
Nick, On Sun, Sep 29, 2002 at 02:51:53PM -0600, Nicholas Leippe wrote: Hi, I was wondering if some dev out there could spend say 2-5 minutes and post an email that lists all of the possible knobs that can be turned. I know there's a bunch, but they're scattered though several postings and hard to find. Check http://dri.sourceforge.net/doc/faq/testing.html#AEN1637 . If you see any other 'knobs' worthy to mention (even not necessarily environment vars) then I would appreciate that you forward them to me so that I can add them to the FAQ as well. For instance, very interesting 'knobs' not mentioned in the FAQ are the driver specific debugging environment variables, such as MACH64_DEBUG, RADEON_DEBUG, and others alike. Due to their specificity and volatility I don't think is worth to have them detailed in the FAQ, but a direct link from the FAQ to the CVS file where they are implemented (and hopefully documented) should be a good idea. Agreed? [...] I keep seeing posts about pageflipping, hw perf boxes, and many other little things to try and get a little frustrated trying to track down the knob to turn them on/off... This could make a good little web page addition to the site as well. José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
On Sun, 29 Sep 2002 22:37:36 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: On Sun, 29 Sep 2002 23:25:03 +0200 Dieter Nützel [EMAIL PROTECTED] wrote: [snip] Is r100/r200 a completely different thing? If not why not a patch against both? Then the testing audience should be much wider. Sure. As far as I could see the code is very similar. However, this: rmesa-do_irqs = (0 rmesa-dri.drmMinor = 6 !getenv(R200_NO_IRQS) rmesa-r200Screen-irq); looks like IRQs are turned off by default on R200. So my code wouldn't be used. Is the reason for IRQs being disabled that the frame throttling is not implemented properly or are there lower level problems with IRQs? No, this is a hangover from the bugs last week. It can be removed now. Ok, I just saw your commit. I'm working on it now. It will take a while, though. The code is ready but I want to compile it at least and I havn't enabled compiling the r200 driver. Is there a faster way than doing a make world after changing config.cf? Keith Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Moving the mouse gives gears 25+ FPS.
With my Radeon 8500 64M running CVS Head 20020928. I get 200FPS and 225FPS when moving the moues /w gears. I also get some jerking(Walls will move back and forth) when moving the mouse(Turning) and strafing in Quake3. __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] knobs to turn?
On Sunday 29 September 2002 03:42 pm, José Fonseca wrote: Check http://dri.sourceforge.net/doc/faq/testing.html#AEN1637 . If you see any other 'knobs' worthy to mention (even not necessarily environment vars) then I would appreciate that you forward them to me so that I can add them to the FAQ as well. A very good start. Didn't know that was there. (/me needs to rtfm more :) For instance, very interesting 'knobs' not mentioned in the FAQ are the driver specific debugging environment variables, such as MACH64_DEBUG, RADEON_DEBUG, and others alike. Due to their specificity and volatility I don't think is worth to have them detailed in the FAQ, but a direct link from the FAQ to the CVS file where they are implemented (and hopefully documented) should be a good idea. Agreed? I think linking to the sources would be good, but it would be better to also actually list them all in one place anyways even if they may be a bit volatile. We can just put a note that they are volatile and to check the sources to be sure. And definitely list everything for all drivers in one page. It is much easier to see everything at once than have to dig through several pages for it all. There are many XF86Config options that have been mentioned--are they documented somewhere (I don't see them in the development faq). They actually belong in a user-visible faq (not develeper specific). I think it would be nice to list all of these in one place regardless of the fact that some would only be used by developers. Nick --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Moving the mouse gives gears 25+ FPS.
Am Montag, 30. September 2002 00:08 schrieb Mike Mestnik: With my Radeon 8500 64M running CVS Head 20020928. I get 200FPS and 225FPS when moving the moues /w gears. I also get some jerking(Walls will move back and forth) when moving the mouse(Turning) and strafing in Quake3. Try setenv R200_NO_USLEEPS 1 (tcsh) or export R200_NO_USLEEPS=1 (bash). But this should be fixed with Keith's/Felix's commit only some minutes ago. The Q3A intro/cinematics stuttering is another one. The hiccup during the game even with UT is under work. -Dieter PS Q3A @ 640x480x32 ~133 fps (without sound), here. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] RE: R128 Problems - The information you requested
On 29 Sep 2002, Jay Phelps wrote: It looks to me like DRI claims to be starting up A-OK. However, glxinfo reports no and gears FPS is as such that it's certainly not using DRI, I'm including my log file for examination. I had something similar the other week. XFree86.log showed that X had enabled DRI fine, but no acceleration worked. Enabling LIBGL_DEBUG showed that any GLX app was unable to load the r200_dri.so file, even though stracing the binary clearly showed that the open of the file (and mmap) succeeded cleanly. R200_DEBUG showed absolutely nothing. Doing a make clean + make World fixed it for me - there's probably something wrong with the dependencies in some makefile. Linus --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] R200_MAX_CLEARS vs R200_MAX_OUTSTANDING
Hello,
Modifying the frame throttling code in r200_ioctl.c I removed
R200_MAX_OUTSTANDING which is no longer needed there. It is, however,
still used in r200Clear:
if ( rmesa-sarea-last_clear - clear = R200_MAX_OUTSTANDING+1 ) {
break;
}
The corresponding radeonClear uses a macro RADEON_MAX_CLEARS. There is a
macro R200_MAX_CLEARS defined in r200_ioctl.c, too. But it is never used.
Did I step on a bug here? Should I change this to
if ( rmesa-sarea-last_clear - clear = R200_MAX_CLEARS ) {
break;
}
Regards,
Felix
__\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_Felix___\Ä/\ \_\ \_\ \__U___just not everything
[EMAIL PROTECTED]o__/ \___/ \___/at the same time!
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] knobs to turn?
On Son, 2002-09-29 at 23:42, José Fonseca wrote: On Sun, Sep 29, 2002 at 02:51:53PM -0600, Nicholas Leippe wrote: Hi, I was wondering if some dev out there could spend say 2-5 minutes and post an email that lists all of the possible knobs that can be turned. I know there's a bunch, but they're scattered though several postings and hard to find. Check http://dri.sourceforge.net/doc/faq/testing.html#AEN1637 . If you see any other 'knobs' worthy to mention (even not necessarily environment vars) then I would appreciate that you forward them to me so that I can add them to the FAQ as well. One that's probably worth adding is LIBGL_THROTTLE_REFRESH to throttle the framerate to the refresh rate. It's only implemented in the radeon and r200 drivers so far but should soon be in mga as well, and others will hopefully follow. For instance, very interesting 'knobs' not mentioned in the FAQ are the driver specific debugging environment variables, such as MACH64_DEBUG, RADEON_DEBUG, and others alike. Due to their specificity and volatility I don't think is worth to have them detailed in the FAQ, but a direct link from the FAQ to the CVS file where they are implemented (and hopefully documented) should be a good idea. Agreed? Yes, and point out that strings /usr/X11R6/lib/modules/dri/driver_dri.so|grep DEBUG and similar is a way to get a list of them. 2D driver options should be documented in the driver manpage and/or /usr/X11R6/lib/X11/Options. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Montag, 30. September 2002 00:41 schrieb Dieter Nützel: Am Sonntag, 29. September 2002 23:48 schrieb Felix Kühling: On Sun, 29 Sep 2002 22:37:36 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: On Sun, 29 Sep 2002 23:25:03 +0200 Dieter Nützel [EMAIL PROTECTED] wrote: [snip] Is r100/r200 a completely different thing? If not why not a patch against both? Then the testing audience should be much wider. Sure. As far as I could see the code is very similar. However, this: rmesa-do_irqs = (0 rmesa-dri.drmMinor = 6 !getenv(R200_NO_IRQS) rmesa-r200Screen-irq); looks like IRQs are turned off by default on R200. So my code wouldn't be used. Is the reason for IRQs being disabled that the frame throttling is not implemented properly or are there lower level problems with IRQs? No, this is a hangover from the bugs last week. It can be removed now. GREAT. Even without Felix new stuff coming soon for the r200, CPU load drops from 100% (gears took 99%, the other CPU was 100% idle) down to 25% for gears on my dual Athlon MP 1900+. 1:28am up 10 min, 1 user, load average: 0.26, 0.28, 0.18 108 processes: 105 sleeping, 3 running, 0 zombie, 0 stopped CPU0 states: 8.0% user, 3.0% system, 0.0% nice, 88.3% idle CPU1 states: 11.0% user, 3.0% system, 0.0% nice, 85.3% idle Mem: 1032728K av, 594820K used, 437908K free, 0K shrd, 311180K buff Swap: 1028120K av, 0K used, 1028120K free 78272K cached PID USER PRI NI SIZE RSS SHARE WCHAN STAT %CPU %MEM TIME COMMAND 3422 nuetzel 15 0 77448 4356 1708 R24.6 0.4 1:21 gears 3442 nuetzel 15 0 1448 1448 1212 R 0.5 0.1 0:02 top 1 root 15 0 212 212 176 schedule_ S 0.0 0.0 0:00 init 2 root 0K 0 00 0 migration SW0.0 0.0 0:00 migration_CPU0 3 root 0K 0 00 0 migration SW0.0 0.0 0:00 migration_CPU1 4 root 15 0 00 0 context_t SW0.0 0.0 0:00 keventd gears is a little bit slower Mesa/demos ./gears r200CreateScreen 4000 frames in 5.001 seconds = 799.840 FPS 11608 frames in 5.000 seconds = 2321.600 FPS 11642 frames in 5.000 seconds = 2328.400 FPS 11612 frames in 5.001 seconds = 2321.936 FPS 11630 frames in 5.000 seconds = 2326.000 FPS then with setenv R200_NO_USLEEPS 1 before Mesa/demos ./gears r200CreateScreen 6465 frames in 5.000 seconds = 1293.000 FPS 11955 frames in 5.000 seconds = 2391.000 FPS 11954 frames in 5.000 seconds = 2390.800 FPS 11955 frames in 5.000 seconds = 2391.000 FPS 11954 frames in 5.000 seconds = 2390.800 FPS Sleep well. -Dieter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: XAA versioning?
On Son, 2002-09-29 at 19:24, Chad Page wrote: On 29 Sep 2002, Michel [ISO-8859-1] Dänzer wrote: On Son, 2002-09-29 at 04:47, Chad Page wrote: I did my own build from CVS and copied libxaa.a from it into the modules directory - 2D and 3D work with one head but I still get signal 11 with two heads, with and without xinerama. I can disable acceleration and it will work, so there seems to be another xaa problem with shared entities. Can you try to track down where the segfault occurs? I tracked it down to radeon_video.c in RadeonResetVideo - the info-accel-sync(pScrn) call causes the sig 11, which would imply that the structure hadn't been fully initialized when called. With that line commented out it works ok, but there's probably a different root cause. What about this patch? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast Index: radeon_video.c === RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_video.c,v retrieving revision 1.11 diff -p -u -r1.11 radeon_video.c --- radeon_video.c 21 Sep 2002 17:08:06 - 1.11 +++ radeon_video.c 29 Sep 2002 23:51:02 - -383,8 +383,9 RADEONResetVideo(ScrnInfoPtr pScrn) unsigned char *RADEONMMIO = info-MMIO; RADEONPortPrivPtr pPriv = info-adaptor-pPortPrivates[0].ptr; +if (info-accel info-accel-Sync) + info-accel-Sync(pScrn); -info-accel-Sync(pScrn); OUTREG(RADEON_OV0_SCALE_CNTL, 0x8000); OUTREG(RADEON_OV0_AUTO_FLIP_CNTL, 0); /* maybe */ OUTREG(RADEON_OV0_EXCLUSIVE_HORZ, 0); -699,7 +700,8 RADEONSetPortAttribute(ScrnInfoPtr pScr RADEONPortPrivPtr pPriv = (RADEONPortPrivPtr)data; Bool setTransform = FALSE; -info-accel-Sync(pScrn); +if (info-accel info-accel-Sync) + info-accel-Sync(pScrn); #define RTFSaturation(a) (1.0 + ((a)*1.0)/1000.0) #define RTFBrightness(a) (((a)*1.0)/2000.0) -799,7 +801,8 RADEONGetPortAttribute(ScrnInfoPtr pScr RADEONInfoPtr info = RADEONPTR(pScrn); RADEONPortPrivPtr pPriv = (RADEONPortPrivPtr)data; -info-accel-Sync(pScrn); +if (info-accel info-accel-Sync) + info-accel-Sync(pScrn); if(attribute == xvAutopaintColorkey) *value = pPriv-autopaint_colorkey; -1016,7 +1019,8 RADEONDisplayVideo( RADEONWaitForFifo(pScrn, 2); OUTREG(RADEON_OV0_REG_LOAD_CNTL, 1); -info-accel-Sync(pScrn); +if (info-accel info-accel-Sync) + info-accel-Sync(pScrn); while(!(INREG(RADEON_OV0_REG_LOAD_CNTL) (1 3))); RADEONWaitForFifo(pScrn, 14);
Re: [Dri-devel] R200_MAX_CLEARS vs R200_MAX_OUTSTANDING
Felix Kühling wrote:
Hello,
Modifying the frame throttling code in r200_ioctl.c I removed
R200_MAX_OUTSTANDING which is no longer needed there. It is, however,
still used in r200Clear:
if ( rmesa-sarea-last_clear - clear = R200_MAX_OUTSTANDING+1 ) {
break;
}
The corresponding radeonClear uses a macro RADEON_MAX_CLEARS. There is a
macro R200_MAX_CLEARS defined in r200_ioctl.c, too. But it is never used.
Did I step on a bug here? Should I change this to
if ( rmesa-sarea-last_clear - clear = R200_MAX_CLEARS ) {
break;
}
Regards,
Felix
What's the story with throttling in glClear? I hope we're not using
glClear as a frame counter of some sort. Applications don't necessarily
have to call glClear at all. Other apps may call glClear several times per
frame.
-Brian
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: XAA versioning?
Nope, dosen't work with that - I still have to comment out the call in RADEONResetVideo. Appears to be a failure within the sync function itself. - Chad On 30 Sep 2002, Michel [ISO-8859-1] Dänzer wrote: On Son, 2002-09-29 at 19:24, Chad Page wrote: On 29 Sep 2002, Michel [ISO-8859-1] Dänzer wrote: On Son, 2002-09-29 at 04:47, Chad Page wrote: I did my own build from CVS and copied libxaa.a from it into the modules directory - 2D and 3D work with one head but I still get signal 11 with two heads, with and without xinerama. I can disable acceleration and it will work, so there seems to be another xaa problem with shared entities. Can you try to track down where the segfault occurs? I tracked it down to radeon_video.c in RadeonResetVideo - the info-accel-sync(pScrn) call causes the sig 11, which would imply that the structure hadn't been fully initialized when called. With that line commented out it works ok, but there's probably a different root cause. What about this patch? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
Am Montag, 30. September 2002 01:45 schrieb Dieter Nützel: Am Montag, 30. September 2002 00:41 schrieb Dieter Nützel: Am Sonntag, 29. September 2002 23:48 schrieb Felix Kühling: On Sun, 29 Sep 2002 22:37:36 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: On Sun, 29 Sep 2002 23:25:03 +0200 Dieter Nützel [EMAIL PROTECTED] wrote: [snip] Is r100/r200 a completely different thing? If not why not a patch against both? Then the testing audience should be much wider. Sure. As far as I could see the code is very similar. However, this: rmesa-do_irqs = (0 rmesa-dri.drmMinor = 6 !getenv(R200_NO_IRQS) rmesa-r200Screen-irq); looks like IRQs are turned off by default on R200. So my code wouldn't be used. Is the reason for IRQs being disabled that the frame throttling is not implemented properly or are there lower level problems with IRQs? No, this is a hangover from the bugs last week. It can be removed now. GREAT. Even without Felix new stuff coming soon for the r200, CPU load drops from 100% (gears took 99%, the other CPU was 100% idle) down to 25% for gears on my dual Athlon MP 1900+. 1:28am up 10 min, 1 user, load average: 0.26, 0.28, 0.18 108 processes: 105 sleeping, 3 running, 0 zombie, 0 stopped CPU0 states: 8.0% user, 3.0% system, 0.0% nice, 88.3% idle CPU1 states: 11.0% user, 3.0% system, 0.0% nice, 85.3% idle Mem: 1032728K av, 594820K used, 437908K free, 0K shrd, 311180K buff Swap: 1028120K av, 0K used, 1028120K free 78272K cached PID USER PRI NI SIZE RSS SHARE WCHAN STAT %CPU %MEM TIME COMMAND 3422 nuetzel 15 0 77448 4356 1708 R24.6 0.4 1:21 gears 3442 nuetzel 15 0 1448 1448 1212 R 0.5 0.1 0:02 top 1 root 15 0 212 212 176 schedule_ S 0.0 0.0 0:00 init 2 root 0K 0 00 0 migration SW0.0 0.0 0:00 migration_CPU0 3 root 0K 0 00 0 migration SW0.0 0.0 0:00 migration_CPU1 4 root 15 0 00 0 context_t SW0.0 0.0 0:00 keventd gears is a little bit slower Mesa/demos ./gears r200CreateScreen 4000 frames in 5.001 seconds = 799.840 FPS 11608 frames in 5.000 seconds = 2321.600 FPS 11642 frames in 5.000 seconds = 2328.400 FPS 11612 frames in 5.001 seconds = 2321.936 FPS 11630 frames in 5.000 seconds = 2326.000 FPS then with setenv R200_NO_USLEEPS 1 before Mesa/demos ./gears r200CreateScreen 6465 frames in 5.000 seconds = 1293.000 FPS 11955 frames in 5.000 seconds = 2391.000 FPS 11954 frames in 5.000 seconds = 2390.800 FPS 11955 frames in 5.000 seconds = 2391.000 FPS 11954 frames in 5.000 seconds = 2390.800 FPS Addition: Q3A only run at full speed (135.6 fps @ 640x480x32) with setenv R200_NO_USLEEPS 1. Without it Q3A is running at 66-76 fps (very shakily). -Dieter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] MGA framerate throttling patch
I've posted an MGA framerate throttling patch at http://people.freebsd.org/~anholt/dri/files/framethrottle5.diff It works fine for me. However, I would like to get some linux users to test it first, particularly with vt switching. Set the LIBGL_THROTTLE_REFRESH environment variable to try it. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/dri/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Spam on this list, list email addresses are out in the open.
Title: RE: [Dri-devel] Spam on this list, list email addresses are out in the open. Set ML submission to moderated for non-subscribers and few persons that check the backlog regularily. Further add e.g. a 24 hours timeout (if possible), so that nothing gets stuck unclassified forever. This way the mails can get filtered out and the regular traffic can reach the destinations. I know several other ML systems, e.g. the gnome project, where it works nice. dont let your ML get misused as distribution system the spammers messages. -Alex.
Re: [Dri-devel] RE: R128 Problems - The information you requested
Thanks for the tip! I rebuilt X and now glxinfo reports DRI in use and glxears confirms it. n Sun, 2002-09-29 at 17:53, Linus Torvalds wrote: On 29 Sep 2002, Jay Phelps wrote: It looks to me like DRI claims to be starting up A-OK. However, glxinfo reports no and gears FPS is as such that it's certainly not using DRI, I'm including my log file for examination. I had something similar the other week. XFree86.log showed that X had enabled DRI fine, but no acceleration worked. Enabling LIBGL_DEBUG showed that any GLX app was unable to load the r200_dri.so file, even though stracing the binary clearly showed that the open of the file (and mmap) succeeded cleanly. R200_DEBUG showed absolutely nothing. Doing a make clean + make World fixed it for me - there's probably something wrong with the dependencies in some makefile. Linus --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] ATI Radeon VE QY (AGP) new drivers (personal) problems
Title: RE: [Dri-devel] ATI Radeon VE QY (AGP) new drivers (personal) problems Hi! here is my problem: I was using the drm drivers wich comes with the 2.4.19 kernel (1.1.1), Sounds stable for me, and compatible to XFree86 4.x.x versions. it was workig right exept fo this: (II) RADEON(0): Using 8 MB AGP aperture it looks like it is only using 8Mb and my [grafics board] has 64Mb AGP-Aperture means a special paging circuit in the mainboard(!) chipset that maps pages of memory into a linear PCI bus memory window. The more precise term for the system is GART and its a subset of the AGP specification which also specifies the AGP transfer modes. Enter your bios and tune your APERTURE SIZE e.g. to 8, 16, 32 or 64 MB. It does not hurt if its too big unless you really allocate the space because it must be backed up by existing main memory. A bit bigger than needed by your applications texture demand is okay because this will avoid fragementation of that page rempaping range. Yes, even the gart range memory pool can be used up. Aperture size and grafics memory size are not related in any way. glxgear only gives 480FPS. I would assume 200 FPS is software rendering, but 480 FPS looks more like hardware rendering. (hmm, or a pretty fast CPU) Can you check with glxinfo if Mesa or hardware rendering is running? Check also with /sbin/lsmod if respective kernel modules are active and countercheck in XF86 logfiles if kernel modules init did succeed. Possilby the most recent beta drivers from the CVS repository might give you much better numbers, but i am not really sure about it. I just dont have a URL handy for you for this resource. mysystem: linux2.4.19, XFree86 4.2.1, AMD Athlon XP 1600+, Asus A7v266-e mb, ati radeon 7000 with 64 mb of memory. Plese if you do repley the do it to the dri-devel list so the most expirienced person in your specific subject will be able to answer the questing. Thanks. -Alex.
Re: [Dri-devel] R200_MAX_CLEARS vs R200_MAX_OUTSTANDING
On Mon, 2002-09-30 at 02:07, Brian Paul wrote:
Felix Kühling wrote:
Hello,
Modifying the frame throttling code in r200_ioctl.c I removed
R200_MAX_OUTSTANDING which is no longer needed there. It is, however,
still used in r200Clear:
if ( rmesa-sarea-last_clear - clear = R200_MAX_OUTSTANDING+1 ) {
break;
}
The corresponding radeonClear uses a macro RADEON_MAX_CLEARS. There is a
macro R200_MAX_CLEARS defined in r200_ioctl.c, too. But it is never used.
Did I step on a bug here? Should I change this to
if ( rmesa-sarea-last_clear - clear = R200_MAX_CLEARS ) {
break;
}
Regards,
Felix
What's the story with throttling in glClear? I hope we're not using
glClear as a frame counter of some sort. Applications don't necessarily
have to call glClear at all. Other apps may call glClear several times per
frame.
RADEON_MAX_CLEARS is 256, so that shouldn't be a problem? OTOH if the
r200 driver uses R200_MAX_OUTSTANDING (which is 2) instead, that could
be limiting...
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] gcc-2.96 radeon snapshot fails
Jose, Unfortunately that doesn't fix the problem for me. I get the same results as before. I loose all visual context, X segfaults and all my VTs are black. I reboot and restore. Sorry I can't give feeback on the other cards. What could the problem be? Do the latest snapshots work on your machine? Maybe a some other change has happened in the CVS that significantly alters things for the snapshots? Incidently, why are the gcc 3.x.x snapshots almost twice as large? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] re: knobs to turn
Nicholas, I have followed the advice that others gave you in their replies and have been able to find the info on environmental variables but I have not looked in the right place for XF86Config Options. Do you know where to find them? I use for my Radeon VIVO (QD) Option AGPMode 4 Option AGPSize 64 Option RingSize 8 Option BufferSize 2 Option EnableDepthMoves true Option EnablePageFlip true Option AGPFastWrite 1 Are there others I've missed? Are these Radeon specific? I have seen in a post for the Voodoo5 the Option DisableSLI 1 or something similar. It would be nice to have ready access to these goodies. I scoured the forums for the ones I found. But where did other people find them? I know RTFM, but which one? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] re: knobs to turn
On Sunday 29 September 2002 10:13 pm, Jason Cook wrote: Nicholas, I have followed the advice that others gave you in their replies and have been able to find the info on environmental variables but I have not looked in the right place for XF86Config Options. Do you know where to find them? Well, it appears that the driver-specific man-pages have them: http://www.xfree86.org/current/manindex4.html However, some man pages are missing, notably ati radeon. Also, these only cover what was available at the 4.2.1 release--not what is currently in DRI CVS. (does dri-cvs contain the man page sources?--I didn't think it did.) I use for my Radeon VIVO (QD) Option AGPMode 4 Option AGPSize 64 Option RingSize 8 Option BufferSize 2 Option EnableDepthMoves true OptionEnablePageFlip true Option AGPFastWrite 1 I only knew about AGPMode and the last two. What do the others do? Are there others I've missed? Are these Radeon specific? I have seen in a post for the Voodoo5 the Option DisableSLI 1 or something similar. It would be nice to have ready access to these goodies. I scoured the forums for the ones I found. But where did other people find them? I know RTFM, but which one? I don't know, that's why I started this thread ;) Nick --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
