[Dri-devel] 2.4.19-rc1 broke i815 agp support?
I got a radeon, after upgrading to 2.4.19-rc1 I can't get direct hardware glx to work, no matter what I try I only get indirect rendering with the tcl branch. Did anyone else try rc1 with radeon? --- 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: Fixed binaries on SF
Hi Jos?! Monday 24, at 10:16:51 PM you wrote: As some of you already noticed, fixed binaries - i.e, including libdri.a -, are now available on SF. When [and if] the binary compatability of libdri.a is restored, let me know and I'll restore the things as they were. Jos? Fonseca Problem is gone away for voodoo3 (again :) DRI is working again after trivial compilation installation binaries. So whats happen? -- with best regards, ICQ: 109916175 JID: [EMAIL PROTECTED] Konstantin Lepikhovmailto:[EMAIL PROTECTED] Motto: Linux is like a wigwam - no windows, no gates, apache inside! --- 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 SourceForge d/l binaries (the ones everyones bitching about)
Hi Dri-devel! Tuesday 25, at 12:16:57 AM you wrote: Hi Smitty! Monday 24, at 12:50:03 PM you wrote: Well after beeing told to upgrade to XF4.2 from XF4.1 I did so: So XF4.2 Indirect rendering install the latest / last binary package from TG XF4.2 with direct rendering (no TCL) compile (not install) the latest binary package (20020623) from SF copy every file to its proper location except radeon_drv.o XF4.2 with direct rendering and TCL hey presto it works! (and is of course way faster than indirect and faster than non-TCL) skip This also works for voodoo driver (i just checked this with 20020623) Thanks! some my friends reported that this method still not work for Radeon cards (Xserver starting but dri not work). Testing in progress... :) -- with best regards, ICQ: 109916175 JID: [EMAIL PROTECTED] Konstantin Lepikhovmailto:[EMAIL PROTECTED] Motto: Linux is like a wigwam - no windows, no gates, apache inside! --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Fixed binaries on SF
On Tue, Jun 25, 2002 at 12:06:36PM +0400, Konstantin Lepikhov wrote: Hi Jos?! Monday 24, at 10:16:51 PM you wrote: As some of you already noticed, fixed binaries - i.e, including libdri.a -, are now available on SF. When [and if] the binary compatability of libdri.a is restored, let me know and I'll restore the things as they were. José Fonseca Problem is gone away for voodoo3 (again :) DRI is working again after trivial compilation installation binaries. So whats happen? What's happened was that changes in libdri.a in the Radeon tcl-0-0-branch which were after included in the trunk broke compatability with previous versions of the library so drivers after this changes require an updated libdri.a. José Fonseca --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] gamma_alloc in drm_context.h
In drm_context.h at line 558 we have: queue = gamma_alloc(sizeof(*queue), DRM_MEM_QUEUES); I think it should be: queue = DRM(alloc)(sizeof(*queue), DRM_MEM_QUEUES); so that it works with driver different from gamma doing alloc_queue. Am I wrong? If not could someone fix that? Already done in my virge branch ; ) Vale, - max lingua --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] S3 VIRGE DRI in CVS now
On Thursday 20 June 2002 13:11, you wrote: I think you should upload it... Other people may be able to help finish it or track down bugs... Ok. Just uploaded the latest and greatest version of my driver in CVS. The branch is named: s3virge-0-0-1-branch 1) Could someone have a try and let me know if everything compile just fine? 2) Could the web page mantainer add virge to supported chipsets (so that interested people will know about it)? Good luck, vale, -max lingua --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)
Would there be an interest in having binary snapshots [on the bleeding-edge] for the s3virge-0-0-1-branch too? José Fonseca On Tue, Jun 25, 2002 at 04:20:36AM -0700, Max Lingua wrote: CVSROOT: /cvsroot/dri Module name: xc Repository:xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ Changes by:sunmax@usw-pr-cvs1. 02/06/25 04:20:36 Log message: Ok. We got 3d hw acceleration on S3 Virge too now ; ) ... --- 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] gamma_alloc in drm_context.h
On Tue, Jun 25, 2002 at 11:53:53 +0200, max wrote: In drm_context.h at line 558 we have: queue = gamma_alloc(sizeof(*queue), DRM_MEM_QUEUES); I think it should be: queue = DRM(alloc)(sizeof(*queue), DRM_MEM_QUEUES); so that it works with driver different from gamma doing alloc_queue. Am I wrong? If not could someone fix that? Already done in my virge branch ; ) Your right. Fixed. Alan. --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)
On Tuesday 25 June 2002 13:37, you wrote: Would there be an interest in having binary snapshots [on the bleeding-edge] for the s3virge-0-0-1-branch too? It could be a good idea for the ones (many users) who are not confortable in building complex projects (like DRI). Unluckily I still don't have a web page (which I would fill with tons of my OpenGL demos + some porting from win opengl app + my drivers code). So if there were interest, where would this binaries be hosted? Vale, - max --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)
On Tue, Jun 25, 2002 at 02:43:39PM +0200, max wrote: On Tuesday 25 June 2002 13:37, you wrote: Would there be an interest in having binary snapshots [on the bleeding-edge] for the s3virge-0-0-1-branch too? It could be a good idea for the ones (many users) who are not confortable in building complex projects (like DRI). Unluckily I still don't have a web page (which I would fill with tons of my OpenGL demos + some porting from win opengl app + my drivers code). So if there were interest, where would this binaries be hosted? In http://dri.sourceforge.net/snapshots/bleeding-edge/ as mach64 branch, the old radeon tcl branch, and soon the radeon 8500 branch, or for any other branch (x86 Linux only I'm afraid). It's just a matter of a few keypresses for me to get the s3virge branch built every night. The only trouble you would have would be to give feedback to the people using those binary snapshots (which could be potential more than those willing to build from CVS directly). Besides this inconvenience, the other reason why I ask before enabling them was to know if the branch is in shape for releasing binary snapshots or if there are any caveats that would prevent that. José Fonseca --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?
Hello There are some Intel815 AGP changes in 2.4.19-rc1, but I am not sure these are the problem. Can you try to run testgart to see if problems are really agp-related ? a+ -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) --- 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: S3 VIRGE DRI in CVS now
On Tue, 2002-06-25 at 09:34, [EMAIL PROTECTED] wrote: Message: 11 From: max [EMAIL PROTECTED] To: Keith Whitwell [EMAIL PROTECTED] Date: Tue, 25 Jun 2002 12:22:01 +0200 Cc: [EMAIL PROTECTED] Subject: [Dri-devel] S3 VIRGE DRI in CVS now On Thursday 20 June 2002 13:11, you wrote: I think you should upload it... Other people may be able to help finish it or track down bugs... Ok. Just uploaded the latest and greatest version of my driver in CVS. The branch is named: s3virge-0-0-1-branch 1) Could someone have a try and let me know if everything compile just fine? 2) Could the web page mantainer add virge to supported chipsets (so that interested people will know about it)? Good luck, vale, -max lingua Is the Virge MX+ supported? This is the one that was commonly found in notebooks, as that is what I will be testing it out on. -- John Tobin [EMAIL PROTECTED]; AOL IM: ogre7929 http://ogre.rocky-road.net http://ogre.rocky-road.net/cdr.shtml --- 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] Mach64 with AGP: still some restrictions onresolution/depth?
I just tried to run my X in 1280x1024/24bpp (before it was 16bpp) and lost DRM! I got it back only in 800x600/24. Now when we have AGP textures working - what are the restrictions on resolutions/color depth? Still no answer..:( Could please anyone tell me why I cannot get 1280x1024/24bpp with AGP texturing? Is this fundamental restriction or just temporary problem? Should this [3 * screen size] be in video memory or total AGP memory would suffice? Also, I noticed X server crashes while changing the resolution (as well as switching to another VTs). Is there a way to track this in order to help fixing? Also, I found another nice GL testing app - glclock. It looks really gorgeous. And it shows a lot of cases where Mach64 still uses SW rendering - the difference in fps is really impressive:) Regards, Sergey --- 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] Mach64 with AGP: still some restrictions on resolution/depth?
On Tue, Jun 25, 2002 at 04:21:51PM +0100, Sergey V. Udaltsov wrote: I just tried to run my X in 1280x1024/24bpp (before it was 16bpp) and lost DRM! I got it back only in 800x600/24. Now when we have AGP textures working - what are the restrictions on resolutions/color depth? Still no answer..:( Could please anyone tell me why I cannot get 1280x1024/24bpp with AGP texturing? Is this fundamental restriction or just temporary problem? Is there anything reported on /var/log/XFree86.0.log or /var/log/messages? Should this [3 * screen size] be in video memory or total AGP memory would suffice? The 3 * screen size restrition refers always on the video memory. Also, I noticed X server crashes while changing the resolution (as well as switching to another VTs). Is there a way to track this in order to help fixing? Yes. Either start X with gdb or attach gdb after X starts but before changing resolution from a remote terminal, e.g.: ssh yourhost ps -A | grep X 28952 ?02:49:17 X gdb /usr/X11R6/bin/X 28952 ... continue Then reproduce the segfault, i.e., change the resolution in this case, the gdb command line should reapper. Type 'bt' and post the result. Also, I found another nice GL testing app - glclock. It looks really gorgeous. And it shows a lot of cases where Mach64 still uses SW rendering - the difference in fps is really impressive:) I didn't followed you. What do you mean with SW rendering and which two situations do the difference in fps refer? José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)
On Tue, Jun 25, 2002 at 02:43:39PM +0200, max wrote: On Tuesday 25 June 2002 13:37, you wrote: Would there be an interest in having binary snapshots [on the bleeding-edge] for the s3virge-0-0-1-branch too? It could be a good idea for the ones (many users) who are not confortable in building complex projects (like DRI). Unluckily I still don't have a web page (which I would fill with tons of my OpenGL demos + some porting from win opengl app + my drivers code). So if there were interest, where would this binaries be hosted? In http://dri.sourceforge.net/snapshots/bleeding-edge/ as mach64 branch, the old radeon tcl branch, and soon the radeon 8500 branch, or for any other branch (x86 Linux only I'm afraid). It's just a matter of a few keypresses for me to get the s3virge branch built every night. The only trouble you would have would be to give feedback to the people using those binary snapshots (which could be potential more than those willing to build from CVS directly). Besides this inconvenience, the other reason why I ask before enabling them was to know if the branch is in shape for releasing binary snapshots or if there are any caveats that would prevent that. José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?
On June 25, 2002 10:43 am, Nicolas Aspert wrote: Hello There are some Intel815 AGP changes in 2.4.19-rc1, but I am not sure these are the problem. Can you try to run testgart to see if problems are really agp-related ? a+ I'm not sure where to find the testgart util (I am indeed running it on an i815B). Could you send me the tarball or give me a url to it? --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
Is there anything reported on /var/log/XFree86.0.log or /var/log/messages? Nothing. In XFree86.0.log there is no word about DRI! I presume it is because of this 3*screen size restriction. Should this [3 * screen size] be in video memory or total AGP memory would suffice? The 3 * screen size restrition refers always on the video memory. And will it always be the same? 1280x1024/24bpp is ... a bit more than my humble 8M:( Yes. Either start X with gdb or attach gdb after X starts but before changing resolution from a remote terminal, e.g.: Then reproduce the segfault, i.e., change the resolution in this case, the gdb command line should reapper. Type 'bt' and post the result. OK. I will try. I didn't followed you. What do you mean with SW rendering and which two situations do the difference in fps refer? I mean indirect (software) rendering. Mach64 uses it in some situations, doesn't it? So one can really feel the difference... Regards, Sergey --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ATI Radeon 7500 Performance Issues
Michel =?ISO-8859-1?Q?D=E4nzer?= writes: On Sat, 2002-06-22 at 14:30, [EMAIL PROTECTED] wrote: 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? There are issues with it, e.g. when obscuring a 3D window. OK 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. Hmm. I'm running out of ideas then... I was just looking through the files and came across this: Jun 23 20:54:44 trinity kernel: [drm:radeon_freelist_get] *ERROR* returning NULL ! Jun 23 20:55:45 trinity last message repeated 638 times Jun 23 20:56:46 trinity last message repeated 195 times Jun 23 20:57:49 trinity last message repeated 366 times Jun 23 20:58:50 trinity last message repeated 354 times But this doesn't seem to be generated when I do a glxgears, only bzflag. Not sure what it means! Crystal space's walktest instantly dies with a walktest: t_imm_api.c:316: _tnl_end: Assertion `ctx-Driver.NeedFlush 0x1' failed. I also see that. I've reported it to the Crystal Space mailing list but have yet to get anything back. Thanks, Matt --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ATI Radeon 7500 Performance Issues
Jun 23 20:55:45 trinity last message repeated 638 times Jun 23 20:56:46 trinity last message repeated 195 times Jun 23 20:57:49 trinity last message repeated 366 times Jun 23 20:58:50 trinity last message repeated 354 times But this doesn't seem to be generated when I do a glxgears, only bzflag. Not sure what it means! The driver is running out of dma buffers - this might be normal, or not. Crystal space's walktest instantly dies with a walktest: t_imm_api.c:316: _tnl_end: Assertion `ctx-Driver.NeedFlush 0x1' failed. I also see that. I've reported it to the Crystal Space mailing list but have yet to get anything back. This is definitely a bug in the driver, not a crystal space problem. If you run with 'RADEON_NO_VTXFMT=t' it should go away. I don't have time to track it down right now. Keith --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?
Slava Polyakov wrote: I'm not sure where to find the testgart util (I am indeed running it on an i815B). Could you send me the tarball or give me a url to it? http://ltswww.epfl.ch/~aspert/patches/testgart.c or http://dri.sourceforge.net/res/testgart.c a+ -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 with AGP: still some restrictions on resolution/depth?
On Tue, Jun 25, 2002 at 05:29:40PM +0100, Sergey V. Udaltsov wrote: Is there anything reported on /var/log/XFree86.0.log or /var/log/messages? Nothing. In XFree86.0.log there is no word about DRI! I presume it is because of this 3*screen size restriction. Strange... When the 3 * screen size is checked an error message is produced and DRI is given as disabled in the X log. Should this [3 * screen size] be in video memory or total AGP memory would suffice? The 3 * screen size restrition refers always on the video memory. And will it always be the same? 1280x1024/24bpp is ... a bit more than my humble 8M:( Even yesterday Leif and I briefly discussed this on the IRC meeting and unfortunately ther seem to be some limitations in Mach64 itself regarding this, i.e., as far as we know it's not possible to put none of the front back and depth buffer on AGP. So unless we dismiss the back buffer I don't see how this restrition will go away. (I don't know how Windows copes with this neither - it's something I still have to check). Yes. Either start X with gdb or attach gdb after X starts but before changing resolution from a remote terminal, e.g.: Then reproduce the segfault, i.e., change the resolution in this case, the gdb command line should reapper. Type 'bt' and post the result. OK. I will try. I didn't followed you. What do you mean with SW rendering and which two situations do the difference in fps refer? I mean indirect (software) rendering. Mach64 uses it in some situations, doesn't it? So one can really feel the difference... Yes, there are some situations, but they don't depend on the available memory and/or screen resolution. So if is this what you were talking about then the difference in fps come solely from less texture trashing. José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Why so difference between root and non root?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The numbers are after some iterations, when they are stable. I think the answer is on your last sentence :) On 22:52, lunedì 24 giugno 2002, Michel Dänzer wrote: On Mon, 2002-06-24 at 22:46, Willy Gardiol wrote: I feel big differences between playng games as root and as non root i have put the mode 666 in the dri section in the xfree config file, i have dri enabled both as root and as non root. glxgears says: as root 770 fps as non root 700 fps Doesn't seem to make a difference here. Beware that the first numbers from glxinfo are unreliable, are these after letting it run for a while? and games are croppy as non root and perfect as root. Maybe some of them take advantage of the root credentials to enhance their scheduling parameters? - -- Willy Gardiol - [EMAIL PROTECTED] goemon.polito.it/~gardiol Use linux for your freedom. Notre Père qui etes aux cieux Restez-y Et nous nous resterons sur la terre Qui est quelquefois si jolie. Padre nostro che sei nei cieli Restaci E noi resteremo sulla terra Che qualche volta è così gradevole. Jacques Prévert (1900-1977) -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9GKaGQ9qolN/zUk4RAo4aAJ9vckzUX4UoZ1lCr+jt5TL9/RPBJgCgq0zR eKzfPd72YTyrGltRg4xqNxA= =euNm -END PGP SIGNATURE- --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
Strange... When the 3 * screen size is checked an error message is produced and DRI is given as disabled in the X log. Sorry for misinformation. After detailed investigation, I found the complain. It just was not prefixed with [drm]:))) So I need 13440K:( Even yesterday Leif and I briefly discussed this on the IRC meeting and unfortunately ther seem to be some limitations in Mach64 itself :((( Why can't you say something nice sometimes? regarding this, i.e., as far as we know it's not possible to put none of the front back and depth buffer on AGP. So unless we dismiss the back buffer I don't see how this restrition will go away. (I don't know how Windows copes with this neither - it's something I still have to check). Is there a way to check in with Windows drivers? It would be very interesting... Well, about back buffer - what would be the penalty of dismissing it? Yes. Either start X with gdb or attach gdb after X starts but before changing resolution from a remote terminal, e.g.: Then reproduce the segfault, i.e., change the resolution in this case, the gdb command line should reapper. Type 'bt' and post the result. OK. I will try. At the moment, I don't have network and second computer but I managed to find in X log - crash is caused by signal 11. And the situation when it appears a bit strange. I can safely switch VTs when I run just X from VT1. Even from login screen of gdm I can switch to VT1. But after I log in into gdm - after this point switching to VT1 causes signal 11. Well, tomorrow I'll try to use gdb remotely... About changing resolutions: well, I can do it in most cases. But when vmware changes the resolution (in full screen mode - AFAIK it does it using DGA, isn't it?) - X crashes the same way. Yes, there are some situations, but they don't depend on the available memory and/or screen resolution. So if is this what you were talking about then the difference in fps come solely from less texture trashing. No, I mean they depend on using different GL effects (anti-aliasing, multi-texturing etc). So in some cases I have HW 3d (and it is reasonably fast) - but in some bad cases glclock switches to SW - and goes VERY slow. BTW, playing with different resolutions (Using Ctl-Alt-+/-) I found that fps in glxgears really depend on resolution. Not too much but still: 800x600 - 267 1024x768 - 259 1280x1024 - 251 Same size, 16bpp. A bit funny, isn't it? Regards, Sergey --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 2.4.19-rc1 broke i815 agp support?
On Tuesday 25 June 2002 19:53, Nicolas Aspert wrote: Slava Polyakov wrote: I'm not sure where to find the testgart util (I am indeed running it on an i815B). Could you send me the tarball or give me a url to it? http://ltswww.epfl.ch/~aspert/patches/testgart.c or http://dri.sourceforge.net/res/testgart.c Some numbers for the AMD 760 MPX chipset. MSI K7D-Master-L (MS-6501) v1.0, BIOS 1.3 Dual Athlon MP 1900+ 512 MB DDR266-SDRAM CL2 dmesg: [-] Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 439M agpgart: Detected AMD 760MP chipset agpgart: AGP aperture is 64M @ 0xe800 memory : c24e0680 memory : c24e06c0 [-] SunWave1 Entwicklung/Kernel# ./testgart version: 0.99 bridge id: 0x700c1022 agp_mode: 0xf000203 aper_base: 0xe800 aper_size: 64 pg_total: 112384 pg_system: 112384 pg_used: 0 entry.key : 0 entry.key : 1 Allocated 8 megs of GART memory MemoryBenchmark: 1372 mb/s MemoryBenchmark: 1407 mb/s MemoryBenchmark: 1434 mb/s Average speed: 1404 mb/s Testing data integrity (1st pass): passed on first pass. Testing data integrity (2nd pass): passed on second pass. Regards, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: [EMAIL PROTECTED] --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Debt Consolidation - Your Key to Cash Flow
Pay Your Bills and get Cash Back Too Now is the time to refinance your home or get a second mortgage to consolidate all of your high interest credit card debt. Get all the Smart Cash you'll need! Cash out your equity while rates are low! (UP TO 125%) All USA Homeowners Easily Qualify! Damaged Credit Is never a problem! We work with nation-wide lenders that are offering great deals and will provide you with the best service on the INTERNET! Our service is 100% free! GO HERE http://www.security-interest.com/LoanEvaluations/ FOR YOUR FREE QUOTE!! To be taken off the list. http://www.security-interest.com/takemeoff/ 7200bCOD5-752nvwy43l18 --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 with AGP: still some restrictions on resolution/depth?
On Tue, Jun 25, 2002 at 09:41:16PM +0100, Sergey V. Udaltsov wrote: Strange... When the 3 * screen size is checked an error message is produced and DRI is given as disabled in the X log. Sorry for misinformation. After detailed investigation, I found the complain. It just was not prefixed with [drm]:))) So I need 13440K:( Even yesterday Leif and I briefly discussed this on the IRC meeting and unfortunately ther seem to be some limitations in Mach64 itself :((( Why can't you say something nice sometimes? regarding this, i.e., as far as we know it's not possible to put none of the front back and depth buffer on AGP. So unless we dismiss the back buffer I don't see how this restrition will go away. (I don't know how Windows copes with this neither - it's something I still have to check). Is there a way to check in with Windows drivers? It would be very As I said before I still have to investigate. I can't give more answers until I actually do it. (PS: reboot my machine to windows is not something I do often or even like to do..) interesting... Well, about back buffer - what would be the penalty of dismissing it? No double buffering, i.e., you would see stuff getting drawed over the previous frame. If the fps are high, that might get unnoticed, but not otherwise. Yes. Either start X with gdb or attach gdb after X starts but before changing resolution from a remote terminal, e.g.: Then reproduce the segfault, i.e., change the resolution in this case, the gdb command line should reapper. Type 'bt' and post the result. OK. I will try. At the moment, I don't have network and second computer but I managed to find in X log - crash is caused by signal 11. And the situation when it appears a bit strange. I can safely switch VTs when I run just X from VT1. Even from login screen of gdm I can switch to VT1. But after I log in into gdm - after this point switching to VT1 causes signal 11. Well, tomorrow I'll try to use gdb remotely... About changing resolutions: well, I can do it in most cases. But when vmware changes the resolution (in full screen mode - AFAIK it does it using DGA, isn't it?) - X crashes the same way. Yes, there are some situations, but they don't depend on the available memory and/or screen resolution. So if is this what you were talking about then the difference in fps come solely from less texture trashing. No, I mean they depend on using different GL effects (anti-aliasing, multi-texturing etc). So in some cases I have HW 3d (and it is reasonably fast) - but in some bad cases glclock switches to SW - and goes VERY slow. BTW, playing with different resolutions (Using Ctl-Alt-+/-) I found that fps in glxgears really depend on resolution. Not too much but still: 800x600 - 267 1024x768 - 259 1280x1024 - 251 Same size, 16bpp. A bit funny, isn't it? This phenomenon was already discussed once here. It has to do with competition over the video memory bandwith between the GPU and the DAC. José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)
On Tue, 2002-06-25 at 16:34, José Fonseca wrote: On Tue, Jun 25, 2002 at 02:43:39PM +0200, max wrote: In http://dri.sourceforge.net/snapshots/bleeding-edge/ as mach64 branch, the old radeon tcl branch, and soon the radeon 8500 branch, or for any other branch (x86 Linux only I'm afraid). OK. It's just a matter of a few keypresses for me to get the s3virge branch built every night. The only trouble you would have would be to give feedback to the people using those binary snapshots (which could be potential more than those willing to build from CVS directly). Not a problem, I will do. Besides this inconvenience, the other reason why I ask before enabling them was to know if the branch is in shape for releasing binary snapshots or if there are any caveats that would prevent that. Well, the driver is quite stable (it will let you run multiple opengl apps too). You will just have to disable 2D acceleration and configure your XF86config. I can write a short README if you want. Vale, - max lingua --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: S3 VIRGE DRI in CVS now
On Tue, 2002-06-25 at 16:48, John J. Tobin wrote: Is the Virge MX+ supported? This is the one that was commonly found in notebooks, as that is what I will be testing it out on. Yep. That is the laptop on which I developed my driver on. so it will run better on it than on everything else ; ) All the virges models should be supported. Vale, -max lingua --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
As I said before I still have to investigate. I can't give more answers until I actually do it. (PS: reboot my machine to windows is not something I do often or even like to do..) Looking forward... No double buffering, i.e., you would see stuff getting drawed over the previous frame. If the fps are high, that might get unnoticed, but not otherwise. :) This phenomenon was already discussed once here. It has to do with competition over the video memory bandwith between the GPU and the DAC. I thought so. Thanks for comments, Sergey --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
8 MB AGP 1280 x 1024 @16bpp, 1024 x 768 @24bpp That's what I have now. 1280x1024 16bpp. And able to run OpenGL apps perfectly. Note that an 8MB PCI card could get 1280x1024@16, but there would only be ~191kB left over for textures, which isn't likely to be useable. Well, but I even run counter-strike in this resolution! Or do I miss something? Well, it's desktop resolution - cstrike runs in 1024x768 window. Does this matter? If anyone is able to run a GL app in Windows at a higher resolution than those listed, please post the maximum resolutions you can use. Make sure you are looking at the actual resolution used by the app, not the desktop resolution. OK. I will do my best to check this. Sergey --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Capturing debugging info without networking
Here is a sort of simple shell script that I just thought of that might make people's lives a little easier. Cut paste this into a file (maybe /usr/local/bin/dri_debug.sh) and then add this line to your equivalent of /etc/rc.local: /bin/sh /usr/local/bin/dri_debug.sh to have it run at boot time to save info from the last crash. Otherwise, just run it any old time to get a snapshot of log data. If there's interest, I'll put together a nice rc script that should work on most distros for distribution with the testing binaries. This is just a mock up (I haven't even run it - I hate dog food ;) of what should be a bit more complicated and grab a few more things, but you get the idea. DRI_DEBUG_DIR=/var/tmp/dri_debug_`date +%d-%b-%Y-%T` mkdir $DRI_DEBUG_DIR cp /var/log/XFree86.0.log $DRI_DEBUG_DIR # this should work, but a grep might be better ... tail -5000 /var/log/messages $DRI_DEBUG_DIR/syslog.log cp /etc/X11/XF86Config* $DRI_DEBUG_DIR ls -l /usr/lib/libGL* $DRI_DEBUG_DIR/usr_GLFiles.txt ls -l /usr/X11R6/lib $DRI_DEBUG_DIR/X11R6_libFiles.txt ldd /usr/X11R6/bin/glxgears $DRI_DEBUG_DIR/ldd_glxgears.txt # any other files ... tar -czf $DRI_DEBUG_DIR.tar.gz $DRI_DEBUG_DIR #rm -rf $DRI_DEBUG_DIR It might be nice to patch xinitrc to do this: glxinfo /var/tmp/glxinfo.txt every time so it can be bundled up, too. Then when people start having problems, the list can expect (somewhat) consistent reports. Lemme know what you think. I take no responsibility for the meltdown of your system ;) -Al Tobey This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the Priority Health Information Services Department at (616) 942-0954. --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 VIRGE DRI in CVS now
On Tue, 2002-06-25 at 19:28, Jens Owen wrote: Wow, looks like you've been busy. Let's see what kind of feedback you get. A bit I had to study (laws + Savage4 docs). A bit I have to workc. A bit I had to drive my Toyota MR2 Roadster. A bit I had to live. ; ) Feedback is starting to rise. Should I announce the branch on freshmeat? Vale, -max lingua --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: s3virge-0-0-1-branch)
On Tue, Jun 25, 2002 at 11:32:59PM +0200, Massimiliano Lingua wrote: On Tue, 2002-06-25 at 16:34, José Fonseca wrote: On Tue, Jun 25, 2002 at 02:43:39PM +0200, max wrote: In http://dri.sourceforge.net/snapshots/bleeding-edge/ as mach64 branch, the old radeon tcl branch, and soon the radeon 8500 branch, or for any other branch (x86 Linux only I'm afraid). OK. It's just a matter of a few keypresses for me to get the s3virge branch built every night. The only trouble you would have would be to give feedback to the people using those binary snapshots (which could be potential more than those willing to build from CVS directly). Not a problem, I will do. Ok. I'll set things up. Besides this inconvenience, the other reason why I ask before enabling them was to know if the branch is in shape for releasing binary snapshots or if there are any caveats that would prevent that. Well, the driver is quite stable (it will let you run multiple opengl Great! apps too). You will just have to disable 2D acceleration and configure your XF86config. I can write a short README if you want. That would be nice. Other drivers effectively disabled the XAA in the CVS itself such as Mach64 did (IIRC it was done in the DDX driver itself). Perhaps you would like to look into it to avoid receiving tons of emails of people who either didn't read or forget to disable XAA in XF86Config...! José Fonseca --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
On 25 Jun 2002, Sergey V. Udaltsov wrote: 8 MB AGP 1280 x 1024 @16bpp, 1024 x 768 @24bpp That's what I have now. 1280x1024 16bpp. And able to run OpenGL apps perfectly. I assume you're referring to Window here, right? I don't think the current cvs will enable DRI at this resolution yet. Note that an 8MB PCI card could get 1280x1024@16, but there would only be ~191kB left over for textures, which isn't likely to be useable. Well, but I even run counter-strike in this resolution! Or do I miss something? Well, it's desktop resolution - cstrike runs in 1024x768 window. Does this matter? I was referring to PCI-only cards here (or the forced PCI driver mode). Do you have an AGP card? With an AGP card, you have plenty of space for textures in AGP, so 1280x1024 should be useable with 8M of card memory. Are you saying that in Windows you can have a 1280x1024 desktop, but cstrike will only run at a max of 1024x768? That would be possible on a PCI-only card with dynamic buffer allocation. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
Vid. mem Card type Max. 3D resolutions
- ---
4 MB Any 800 x 600 @16bpp, 640 x 480 @24bpp
6 MB PCI 1024 x 768 @16bpp, 800 x 600 @24bpp
6 MB AGP 1152 x 864 @16bpp, 800 x 600 @24bpp
8 MB PCI 1152 x 864 @16bpp, 800 x 600 @24bpp
8 MB AGP 1280 x 1024 @16bpp, 1024 x 768 @24bpp
Also, one more question (I already asked it some while ago but hopefully
the answer has changed):
Is this the desktop resolution on X startup or on GL program startup? So
if I start X in 1280x768x16bpp and then run glapp in 800x600 - will it
leave more video memory for textures?
Sergey
---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
On Tue, 25 Jun 2002, Leif Delgass wrote: On 25 Jun 2002, Sergey V. Udaltsov wrote: 8 MB AGP 1280 x 1024 @16bpp, 1024 x 768 @24bpp That's what I have now. 1280x1024 16bpp. And able to run OpenGL apps perfectly. I assume you're referring to Window here, right? I don't think the current cvs will enable DRI at this resolution yet. Sorry, that's not right. I think the driver _should_ enable DRI at this resolution with the current cvs. It's 1024x768 @24 that doesn't work with the current code. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] S3 VIRGE DRI in CVS now
If the critical feedback is already big now, then first fix a bit in drivers and then widen the testing audience. A bit I had to study (laws + Savage4 docs). A bit I have to workc. A bit I had to drive my Toyota MR2 Roadster. A bit I had to live. ; ) Feedback is starting to rise. Should I announce the branch on freshmeat? Vale, -max lingua --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 with AGP: still some restrictions onresolution/depth?
That's what I have now. 1280x1024 16bpp. And able to run OpenGL apps perfectly. I assume you're referring to Window here, right? I don't think the current cvs will enable DRI at this resolution yet. Well, I run it with DRI/Linux+XFree4.2.0. My screen resolution is 1280x1024 16bpp: Subsection Display Depth 16 Modes 1280x1024 1024x768 800x600 And I do have DRI working for me. Surprise?:) Do you have an AGP card? With an AGP card, you have plenty of space for Yes I do have AGP 2x in my laptop Mobility. textures in AGP, so 1280x1024 should be useable with 8M of card memory. But not in 24bpp:( Are you saying that in Windows you can have a 1280x1024 desktop, but cstrike will only run at a max of 1024x768? That would be possible on a PCI-only card with dynamic buffer allocation. In LINUX I have 1280x1024 desktop and run cstrike in 1024x768 (using wine from Transgaming, sure). 16bpp, naturally. Sergey --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: Radeon SourceForge d/l binaries (the ones everyones bitching about)
Hei some my friends reported that this method still not work for Radeon cards (Xserver starting but dri not work). Testing in progress... :) Me neither (I have a radeon) however it works as root / su (even in a virtual terminal under X logged in as a normal user where it wont work) which makes me think permissions, this even happens if I just install the TG binary packages. I mentioned this in a previous email, hence: This curently works as root on my box. But apperently its fixed with the latest binary packages from SF, although when I tested 20020624 last night it killed X, so... Will try 20020625 tonight. Liam it depends --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
