[Dri-devel] Re: pbuffers, extensions to DRM
Jon Smirl wrote: My current thinking on this is to do it the DRM driver but store the allocation data in normal system RAM. This would allow the allocation routines to function without touching the framebuffer. I would really like to make sure that DRM drivers can function without having to map the framebuffer into kernel address space. We only have 1GB of kernel address space to work with and the kernel has to live in that 1GB too. 3dlabs is shipping a 512MB card now: http://www.3dlabs.com/product/wildcatvp/vppro/index.htm and a 1GB model is in the works. It is just going to be impossible to map these future cards into the kernel. ... I've also been poking around a little in the radeon DRM driver. It seems to be mapping the framebuffer into kernel space but I never see any place that the driver code touches it. Correct. There's nowhere the kernel needs to touch the framebuffer. Keith --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] FW: S3 TwisterK...
the admin list got this, i think it is ment to the main list. forwarding it now, just to get it right... -Original Message- From: TA [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 19:55 To: [EMAIL PROTECTED] Subject: S3 TwisterK... Hi DRi Team! I've got a notebook with S3 TwisterK, I'd like to use Linux, but only with hardware opengl support. I'd like to ask, that will next DRI driver package have ProSavage and Twister support? If not, when will have? Many Thanks! Bye! Best Wishes: Antoine Trifonov --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon 9000 and latest CVS produce freezes on dual opteron system with 1 GL app using texturing.
Am Dienstag, 09. Dezember 2003 02:22 schrieb Michel Dnzer: On Fri, 2003-12-05 at 00:24, [EMAIL PROTECTED] wrote: I am trying to get a Radeon 9000 pro to work using the latest DRI CVS tree, but encountering a few problems. The system in question is a pair of opterons running on a Tyan S2885 board, with Suse 9.0 Professional (AMD64) installed and the latest 2.4.21-149 kernel. I get the same results whether building/installing the whole tree, or building/installing just the radeon.o module. After manually modprobing agpgart, and starting X, glxinfo reports that direct rendering is enabled, and I can run either multiple GL apps or instances of apps that do not use textures (like glxgears, or bubble3d from the xscreensaver modules), or a single instance of a GL app that uses textures. Attempting to run more than one GL app with at least one of the apps using textures results in the apps freezing up, and the keyboard locking. The mouse cursor still responds, but not the buttons. If you have network access to the box, and you can still log in after this happens, which process hogs the CPU, and what happens when you kill it? Appear on all (?) SMP systems so far for some months... Even Quake3 didn't run in SMP mode (quake3-smp) anymore (after Ian's context rearrangements). I havent't had enough time and a broken system disks to examine even further in the past weeks. dual Athlon MP 1900+ R200, 64 MB Please try two gears, then gears and ipers and then two instances of ipers. Greetings, Dieter -- Dieter Ntzel @home: Dieter.Nuetzel () hamburg ! de --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: pbuffers, extensions to DRM
On Tue, 2003-12-09 at 02:12, Jon Smirl wrote: -- Michel Dnzer [EMAIL PROTECTED] wrote: I think at least the core of it definitely has to be in the kernel for enforceability, cleanup on process death etc. You're and expert on the radeon driver, want to help code this up? You're flattering me ;), unfortunately I likely won't have time to do any significant work until the end of the year at least. This is basically texmem-2 territory, right Ian? What's the status on that? I'm pondering whether the DRM is really the right place for this; maybe it would rather be a low-level mini-driver as suggested by Linus? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 881] 3D acceleration doesn't work
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=881 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 07:48 --- Are you using the kernel modules provided in the XFree86 CVS too or the ones from your kernel build ? A bigger excerpt from dmesg will accomplish this. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] MGA font corruption revisited - now reproducible
Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
[Dri-devel] ATI Rage Mobility
Hi! I have an old G3 iBook with an ATI Rage Mobility, and there seems to be no hardware acceleration available with neither XFree86 nor DRI :( Has anyone tried to get it working? (who? and where can I get the code?) If not: Is it possible to get it working and how/where should I start? How do i get the specs? from ATI? I am not subscribed to this list (yet) so please CC me! Best regards Tomas Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
turn off HW render accel. both HW render and 3D use the 3D engine and I don't know if they both keep state properly. that's probably were your corruption comes from. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ATI Rage Mobility
you should find what you need here: http://dri.sourceforge.net/cgi-bin/moin.cgi/ATIMach64 I'm not sure anyone has tested it on PPC yet though. Alex --- Tomas Groth [EMAIL PROTECTED] wrote: Hi! I have an old G3 iBook with an ATI Rage Mobility, and there seems to be no hardware acceleration available with neither XFree86 nor DRI :( Has anyone tried to get it working? (who? and where can I get the code?) If not: Is it possible to get it working and how/where should I start? How do i get the specs? from ATI? I am not subscribed to this list (yet) so please CC me! Best regards Tomas __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI newmesa merge
I'm going to merge the newmesa branch to the trunk in a few moments. I've giving people a heads up that I'm going to delete the xc/extras/Mesa directory and insist on people checking out a copy of Mesa's newtree and people setting that in their xc/config/cf/host.def file to point to their checked out copy. I think it's pointless trying to keep merging back and forth now once this merge is complete. Does anyone disagree ? We'll probably need to update the build instructions on the web pages too. Jose ?? Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
By turn off HW render, you mean RenderAccel off, or NoAccel on ? BTW, I should clarify my previous post by saying that the fonts across _all_ Xft applications are corrupted when any of them is corrupted by DRI usage; no other non-AA fonts or pixmap data are affected, however. It is only AA fonts, and across _all_ AA applications when it occurs. Would installing a debug X server help track the cause of the corruption down? On Tue, Dec 09, 2003 at 06:59:30AM -0800, Alex Deucher wrote: turn off HW render accel. both HW render and 3D use the 3D engine and I don't know if they both keep state properly. that's probably were your corruption comes from. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] DRI newmesa merge
On Tue, 9 Dec 2003 15:11:06 + Alan Hourihane [EMAIL PROTECTED] wrote: I'm going to merge the newmesa branch to the trunk in a few moments. I've giving people a heads up that I'm going to delete the xc/extras/Mesa directory and insist on people checking out a copy of Mesa's newtree and people setting that in their xc/config/cf/host.def file to point to their checked out copy. I think it's pointless trying to keep merging back and forth now once this merge is complete. Does anyone disagree ? We'll probably need to update the build instructions on the web pages too. Jose ?? And the snapshot build scripts. I'm going to do that for the freedesktop ones tonight. Alan. Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
renderaccel. the reason for the curruption is that both the 2d driver and the 3d driver are using the 3d engine. since they are not keeping state (render accel my write on 3d textures and vice versa, etc.), games will corrupt fonts and vice versa. Unfortunately it's a tough problem to solve. I don't recall how you turn off render accel on mga, you can probably find that on google. turning it off should solve the problem since render (used for AA fonts) will use teh software paths instead. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: By turn off HW render, you mean RenderAccel off, or NoAccel on ? BTW, I should clarify my previous post by saying that the fonts across _all_ Xft applications are corrupted when any of them is corrupted by DRI usage; no other non-AA fonts or pixmap data are affected, however. It is only AA fonts, and across _all_ AA applications when it occurs. Would installing a debug X server help track the cause of the corruption down? On Tue, Dec 09, 2003 at 06:59:30AM -0800, Alex Deucher wrote: turn off HW render accel. both HW render and 3D use the 3D engine and I don't know if they both keep state properly. that's probably were your corruption comes from. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI newmesa merge
Alan Hourihane wrote: I'm going to merge the newmesa branch to the trunk in a few moments. I've giving people a heads up that I'm going to delete the xc/extras/Mesa directory and insist on people checking out a copy of Mesa's newtree and people setting that in their xc/config/cf/host.def file to point to their checked out copy. I think it's pointless trying to keep merging back and forth now once this merge is complete. Does anyone disagree ? We'll probably need to update the build instructions on the web pages too. Jose ?? It's probably worth pointing out that in addition to a major rearrangment of the DRI build process, this merge effectively pulls in Mesa 5.x, which includes a lot of new code, and of particular relevence a rewrite of the mesa/tnl module for handling vertex data. So, it's probably worthwhile for everybody to get up to speed on this new code as soon as possible (once the merge has settled down, etc). There are bound to be some latent bugs in there... Keith --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI newmesa merge
How should this affect DRI 3d drivers? According to the documenation: http://dri.sourceforge.net/doc/DRIintro.html it says Most DRI 3D drivers today are based on Mesa. How so? Is it that the 3d drivers (_dri.so's) use the Mesa Library to to catch OpenGL calls and map them onto hardware events? I know Mesa does software rendering but I'm just not grasping exactly what Mesa's role is for when no software rendering is used. And last, should I then test again the IGP patch with the latest merge to see if I notice any significant changes with the new Mesa merge? This should probably go in a another e-mail thread but what sort of more tests are left before merging IGP patch into DRI cvs tree? Luis On Tue, 9 Dec 2003, Keith Whitwell wrote: Alan Hourihane wrote: I'm going to merge the newmesa branch to the trunk in a few moments. I've giving people a heads up that I'm going to delete the xc/extras/Mesa directory and insist on people checking out a copy of Mesa's newtree and people setting that in their xc/config/cf/host.def file to point to their checked out copy. I think it's pointless trying to keep merging back and forth now once this merge is complete. Does anyone disagree ? We'll probably need to update the build instructions on the web pages too. Jose ?? It's probably worth pointing out that in addition to a major rearrangment of the DRI build process, this merge effectively pulls in Mesa 5.x, which includes a lot of new code, and of particular relevence a rewrite of the mesa/tnl module for handling vertex data. So, it's probably worthwhile for everybody to get up to speed on this new code as soon as possible (once the merge has settled down, etc). There are bound to be some latent bugs in there... Keith --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 12:51 --- ok people, i have uninstalled Fedora as it is very buggy, I now installed SuSE 9 and so far i am much happier with it, it picks up my igp 340m but doesnt have 3d available, only 2d works, later on tonight at work i will go through patching process and hopefully i will have a much successfull install. Does anybody else here use SuSE? if so please let me know! Anyways, i will post later on and see everything... I know that Xfree86 4.4 is going to be released soon? in this next release will there be drivers and 3d available for igp 340m or will we still have to patch? Also, once i have patched dri etc, do i have to recompile my kernel? or can i just leave everything as is with /usr/src/linux? speak soon, Mixhael. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI newmesa merge
--- Alan Hourihane [EMAIL PROTECTED] wrote: So Mesa/newtree is going to be the master copy of the dri drivers, including the ones in mesa/dri/drivers? I'm all for that after doing the merge a couple of times. I've giving people a heads up that I'm going to delete the xc/extras/Mesa directory and insist on people checking out a copy of Mesa's newtree and people setting that in their xc/config/cf/host.def file to point to their Is this going to cause a lot of anon cvs load that currently is on freedesktop.org to revert back to sf.net (with all of it's problems)? Does mesa need to move cvs to freedesktop now? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI newmesa merge
Jon Smirl wrote: --- Alan Hourihane [EMAIL PROTECTED] wrote: So Mesa/newtree is going to be the master copy of the dri drivers, including the ones in mesa/dri/drivers? I'm all for that after doing the merge a couple of times. Yes. I've giving people a heads up that I'm going to delete the xc/extras/Mesa directory and insist on people checking out a copy of Mesa's newtree and people setting that in their xc/config/cf/host.def file to point to their Is this going to cause a lot of anon cvs load that currently is on freedesktop.org to revert back to sf.net (with all of it's problems)? Does mesa need to move cvs to freedesktop now? Quite probably. Let's give sf.net a couple of days trial and see if they've gotten their act together. Keith --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI newmesa merge
On Tue, Dec 09, 2003 at 09:58:44AM -0800, Jon Smirl wrote: --- Alan Hourihane [EMAIL PROTECTED] wrote: So Mesa/newtree is going to be the master copy of the dri drivers, including the ones in mesa/dri/drivers? I'm all for that after doing the merge a couple of times. Yes. I've giving people a heads up that I'm going to delete the xc/extras/Mesa directory and insist on people checking out a copy of Mesa's newtree and people setting that in their xc/config/cf/host.def file to point to their Is this going to cause a lot of anon cvs load that currently is on freedesktop.org to revert back to sf.net (with all of it's problems)? Does mesa need to move cvs to freedesktop now? I guess that's Brian's call. I don't believe he had intentions to move it. I think SourceForge has fixed the CVS problems of times gone by. Fingers crossed. Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] DRI newmesa merge
Alan Hourihane wrote: On Tue, Dec 09, 2003 at 09:58:44AM -0800, Jon Smirl wrote: --- Alan Hourihane [EMAIL PROTECTED] wrote: So Mesa/newtree is going to be the master copy of the dri drivers, including the ones in mesa/dri/drivers? I'm all for that after doing the merge a couple of times. Yes. I've giving people a heads up that I'm going to delete the xc/extras/Mesa directory and insist on people checking out a copy of Mesa's newtree and people setting that in their xc/config/cf/host.def file to point to their Is this going to cause a lot of anon cvs load that currently is on freedesktop.org to revert back to sf.net (with all of it's problems)? Does mesa need to move cvs to freedesktop now? I guess that's Brian's call. I don't believe he had intentions to move it. I think SourceForge has fixed the CVS problems of times gone by. If SF's CVS causes problems, I'm OK with moving Mesa to freedesktop. -Brian --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI newmesa merge
Luis R. Rodriguez wrote: How should this affect DRI 3d drivers? According to the documenation: http://dri.sourceforge.net/doc/DRIintro.html it says Most DRI 3D drivers today are based on Mesa. How so? Is it that the 3d drivers (_dri.so's) use the Mesa Library to to catch OpenGL calls and map them onto hardware events? I know Mesa does software rendering but I'm just not grasping exactly what Mesa's role is for when no software rendering is used. Even if the hardware is rendering everything, you need Mesa to do the following: * maintain all the GL state * implement the GL API calls * do error checking for API calls * handle building/executing display lists * lots of other stuff -Brian --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI newmesa merge
Alan Hourihane wrote: I'm going to merge the newmesa branch to the trunk in a few moments. I've giving people a heads up that I'm going to delete the xc/extras/Mesa directory and insist on people checking out a copy of Mesa's newtree and people setting that in their xc/config/cf/host.def file to point to their checked out copy. I think it's pointless trying to keep merging back and forth now once this merge is complete. Another thing should be pointed out: since Mesa CVS is goint to be used by more people, we have to be more careful with our check-ins so we never break the build. My plans is this: * wrap up the Mesa 5.1 (development) release soon * rev it to version 6.0 (stable version) which advertises OpenGL 1.5 support * Create a mesa_6_0_branch which people should check out and use for DRI building. This branch will be the stable branch for bug fixes only. * The Mesa CVS trunk will then be for new development again I'll try to get a Mesa 5.1 release candidate put together ASAP. -Brian --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 716] GLX applications/commands very slow on ATI rage128
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=716 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 13:57 --- According to your log file, libdri.a is not loading, but it's specified in your XF86Config file. Are you sure you've got the right XF86Config file or that you've not removed the line that says... Load dri -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 716] GLX applications/commands very slow on ATI rage128
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=716 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 14:00 --- Yes, I know your complaining about slow loading times, so I'd also run ldconfig to ensure your ld.so.cache file is up-to-date. And check the output of 'ldd /usr/X11R6/bin/glxinfo' which will tell you which libraries are going to get loaded upon execution of a GL app. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI newmesa merge
Did the DRM device drivers get moved too? They generally have to be changed in tandem with the 3D drivers. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
Thanks for the insight. Is this already something that has been extensively looked at without success, or would it be worth my time to dig into the code and try to find the cause? I've thought about it, but afraid that I will just hit a brick wall someone else already ran into with it. ;) Is there anywhere I can get a G400 databook for reference, or is that not publicly available? On Tue, Dec 09, 2003 at 07:55:20AM -0800, Alex Deucher wrote: renderaccel. the reason for the curruption is that both the 2d driver and the 3d driver are using the 3d engine. since they are not keeping state (render accel my write on 3d textures and vice versa, etc.), games will corrupt fonts and vice versa. Unfortunately it's a tough problem to solve. I don't recall how you turn off render accel on mga, you can probably find that on google. turning it off should solve the problem since render (used for AA fonts) will use teh software paths instead. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: By turn off HW render, you mean RenderAccel off, or NoAccel on ? BTW, I should clarify my previous post by saying that the fonts across _all_ Xft applications are corrupted when any of them is corrupted by DRI usage; no other non-AA fonts or pixmap data are affected, however. It is only AA fonts, and across _all_ AA applications when it occurs. Would installing a debug X server help track the cause of the corruption down? On Tue, Dec 09, 2003 at 06:59:30AM -0800, Alex Deucher wrote: turn off HW render accel. both HW render and 3D use the 3D engine and I don't know if they both keep state properly. that's probably were your corruption comes from. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___
Re: [Mesa3d-dev] Re: [Dri-devel] DRI newmesa merge
Jon Smirl wrote: Did the DRM device drivers get moved too? They generally have to be changed in tandem with the 3D drivers. Not yet. Let's just get what we've done working tested. The DRM drivers have a proper, versioned interface to the driver, so a lot of the arguments about co-evolution aren't as strong. Keith --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
You could dig into it if you wish. if this is indeed the problem, you will have to figure out a way to maintain the state of the 3d enigne between the render accel and the DRI. you might want to ask Ian about it. you can also check the archives. there was some discussion about this in regards to using the 3d engine on radeon for Xv (YUV textures) and render accel. databooks were available, but I'm not sure they are giving them out anymore. Although I doubt you will really need them as the code is already there, you just need to make it play nice. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Thanks for the insight. Is this already something that has been extensively looked at without success, or would it be worth my time to dig into the code and try to find the cause? I've thought about it, but afraid that I will just hit a brick wall someone else already ran into with it. ;) Is there anywhere I can get a G400 databook for reference, or is that not publicly available? On Tue, Dec 09, 2003 at 07:55:20AM -0800, Alex Deucher wrote: renderaccel. the reason for the curruption is that both the 2d driver and the 3d driver are using the 3d engine. since they are not keeping state (render accel my write on 3d textures and vice versa, etc.), games will corrupt fonts and vice versa. Unfortunately it's a tough problem to solve. I don't recall how you turn off render accel on mga, you can probably find that on google. turning it off should solve the problem since render (used for AA fonts) will use teh software paths instead. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: By turn off HW render, you mean RenderAccel off, or NoAccel on ? BTW, I should clarify my previous post by saying that the fonts across _all_ Xft applications are corrupted when any of them is corrupted by DRI usage; no other non-AA fonts or pixmap data are affected, however. It is only AA fonts, and across _all_ AA applications when it occurs. Would installing a debug X server help track the cause of the corruption down? On Tue, Dec 09, 2003 at 06:59:30AM -0800, Alex Deucher wrote: turn off HW render accel. both HW render and 3D use the 3D engine and I don't know if they both keep state properly. that's probably were your corruption comes from. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 15:03 --- Hi Michael, I am on SuSE 9.0 with an IGP 320M. Installation process should be the same for you. You have to patch and compile a kernel with IGP-Support and you have to patch and compile the XFree86-Sources e.g. (ftp://ftp.xfree86.org/pub/XFree86/develsnaps/XFree86-4.3.99.16.tar.bz2 with http://bugs.xfree86.org/attachment.cgi?id=723action=view). There will be no 3D support in XFree86 4.4 because feature freeze is over. Thomas -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 716] GLX applications/commands very slow on ATI rage128
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=716 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 15:10 --- Please read my 1st comment where it says This is irrespective of whether DRI is enabled or disabled.. This means the problem is there whether or not DRI is enabled. Also, regarding ld.so.cache being not updated, please read my 1st comment where it says On the same system, GLX apps/commands run with no such startup delay if the X display is set on another video card (voodoo3 PCI video card, tdfx driver). Obviously, there is no reason why ld.so.cache should be updated for one display and not for the other. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 716] GLX applications/commands very slow on ATI rage128
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=716 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 15:21 --- True. I suggest you try the latest XFree86 CVS to see if your problem is solved there seeing as XFree86 4.4.0 is around the corner and report back. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon 9000 and latest CVS produce freezes on dual opteron system with 1 GL app using texturing.
Am Dienstag, 09. Dezember 2003 02:22 schrieb Michel Dänzer: On Fri, 2003-12-05 at 00:24, [EMAIL PROTECTED] wrote: I am trying to get a Radeon 9000 pro to work using the latest DRI CVS tree, but encountering a few problems. The system in question is a pair of opterons running on a Tyan S2885 board, with Suse 9.0 Professional (AMD64) installed and the latest 2.4.21-149 kernel. I get the same results whether building/installing the whole tree, or building/installing just the radeon.o module. After manually modprobing agpgart, and starting X, glxinfo reports that direct rendering is enabled, and I can run either multiple GL apps or instances of apps that do not use textures (like glxgears, or bubble3d from the xscreensaver modules), or a single instance of a GL app that uses textures. Attempting to run more than one GL app with at least one of the apps using textures results in the apps freezing up, and the keyboard locking. The mouse cursor still responds, but not the buttons. If you have network access to the box, and you can still log in after this happens, which process hogs the CPU, and what happens when you kill it? I've tried. X is sucking up all of one CPU. It seems that the app(s) using GL textures has/have died. Everything is very slow. If I run top, top itself claims to take up 50% of the other CPU. As this is a dual opteron system, it shouldn't be lack of sheer horsepower. kill -9 pid of X just zombifies X. Nothing I can kill will give me back console access. If I reboot the system from my ssh login (i.e. - init 6), there is a long pause, and then the box emits a continual loud BEP until I power cycle it. Appear on all (?) SMP systems so far for some months... Even Quake3 didn't run in SMP mode (quake3-smp) anymore (after Ian's context rearrangements). I havent't had enough time and a broken system disks to examine even further in the past weeks. dual Athlon MP 1900+ R200, 64 MB Please try two gears, then gears and ipers and then two instances of ipers. I can't completely verify this diagnosis. If I compile/run a uniprocessor kernel (same config otherwise as the SMP one), I get what so far appears to be a longer (and still varying) but finite amount of time before the same behavior appears. So far I have been able to start a few more texturing GL apps before the hang occurs, but it still occurs. Still, nothing obvious turns up in /var/log/messages or XFree86.0.log or ..X.err. With the uniprocessor setup, I have been able to kill X after logging in remotely, as well as whatever GL app may/may not be sucking up process time. So far, (3 tries; I'll keep collecting statistical data.) I've been able to restart the machine once from the remote login. The other times I tried to restart it remotely, it froze harder and refused any further connection attempts. - [EMAIL PROTECTED] PENGUIN COMPUTING www.penguincomputing.com --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 716] GLX applications/commands very slow on ATI rage128
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=716 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 17:10 --- Does it also happen with a local connection to a :0 display? There used to be a buglet where some code on the client side would insist on trying to connect to :0 no matter what DISPLAY contains, no idea whether this has ever been fixed. (BTW, no r128 specific code is used with indirect rendering) -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 716] GLX applications/commands very slow on ATI rage128
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=716 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 17:15 --- Good point Michel. I bet this is it. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Build fails
Hi, I tried to compile the new dri trunk on freedesktop.org now. I checked out Mesa-newtree and set the MesaSrcDir correctly in host.def and ran make World. These are the last few lines of make output: gcc-3.3 -c -O2 -gstabs+ -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -pipe -g -I../../../lib/X11 -I../../../include/extensions -I../../../programs/Xserver/hw/xfree86/os-support -I. -I../../../lib/GL/glx -I../../../exports/include/X11 -I../../../programs/Xserver/GL/dri -I../../../lib/GL/include -I/home/fxkuehl/snapshots/src/Mesa-newtree/include -I/home/fxkuehl/snapshots/src/Mesa-newtree/src/mesa/main -I/home/fxkuehl/snapshots/src/Mesa-newtree/src/mesa/glapi -I../../.. -I../../../exports/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DDEFAULT_DRIVER_DIR=\/usr/X11R6/lib/modules/dri\ dri_util.c In file included from ../../../lib/GL/glx/glxclient.h:50, from dri_util.h:57, from dri_util.c:31: /home/fxkuehl/snapshots/src/Mesa-newtree/include/GL/glx.h:296: warning: function declaration isn't a prototype dri_util.c: In function `findConfigMode': dri_util.c:128: error: structure has no member named `next' dri_util.c:129: error: structure has no member named `visualID' dri_util.c: In function `__driFindDrawable': dri_util.c:161: warning: dereferencing type-punned pointer will break strict-aliasing rules dri_util.c: In function `__driRemoveDrawable': dri_util.c:173: warning: dereferencing type-punned pointer will break strict-aliasing rules dri_util.c: In function `__driGarbageCollectDrawables': dri_util.c:210: warning: dereferencing type-punned pointer will break strict-aliasing rules dri_util.c:221: warning: dereferencing type-punned pointer will break strict-aliasing rules dri_util.c: In function `driCreateNewDrawable': dri_util.c:704: error: structure has no member named `screen' dri_util.c:724: error: structure has no member named `screen' dri_util.c:726: error: structure has no member named `screen' dri_util.c:728: error: structure has no member named `screen' dri_util.c:739: error: structure has no member named `screen' dri_util.c: In function `__driUtilCreateScreen': dri_util.c:1027: error: structure has no member named `screen' dri_util.c:1029: error: structure has no member named `next' make[5]: *** [dri_util.o] Error 1 make[5]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/xc/lib/GL/dri' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/xc/lib/GL' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/xc/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/xc' make[1]: *** [World] Error 2 make[1]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/xc' make: *** [World] Error 2 make: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/xc' I don't have time to look into it now. I'll get back to it tomorrow and look into it myself if it isn't fixed by then. Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Build fails
This sounds to me like you are picking up a stale copy of glcore.h from somewhere. There shouldn't be a xc/lib/GL/include/GL/internal/glcore.h any more, it'll use the one from Mesanew in Mesa-newtree/include/GL/internal/glcore.h. Alan. On Tue, Dec 09, 2003 at 11:26:00PM +0100, Felix Kühling wrote: Hi, I tried to compile the new dri trunk on freedesktop.org now. I checked out Mesa-newtree and set the MesaSrcDir correctly in host.def and ran make World. These are the last few lines of make output: gcc-3.3 -c -O2 -gstabs+ -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -pipe -g -I../../../lib/X11 -I../../../include/extensions -I../../../programs/Xserver/hw/xfree86/os-support -I. -I../../../lib/GL/glx -I../../../exports/include/X11 -I../../../programs/Xserver/GL/dri -I../../../lib/GL/include -I/home/fxkuehl/snapshots/src/Mesa-newtree/include -I/home/fxkuehl/snapshots/src/Mesa-newtree/src/mesa/main -I/home/fxkuehl/snapshots/src/Mesa-newtree/src/mesa/glapi -I../../.. -I../../../exports/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DDEFAULT_DRIVER_DIR=\/usr/X11R6/lib/modules/dri\ dri_util.c In file included from ../../../lib/GL/glx/glxclient.h:50, from dri_util.h:57, from dri_util.c:31: /home/fxkuehl/snapshots/src/Mesa-newtree/include/GL/glx.h:296: warning: function declaration isn't a prototype dri_util.c: In function `findConfigMode': dri_util.c:128: error: structure has no member named `next' dri_util.c:129: error: structure has no member named `visualID' dri_util.c: In function `__driFindDrawable': dri_util.c:161: warning: dereferencing type-punned pointer will break strict-aliasing rules dri_util.c: In function `__driRemoveDrawable': dri_util.c:173: warning: dereferencing type-punned pointer will break strict-aliasing rules dri_util.c: In function `__driGarbageCollectDrawables': dri_util.c:210: warning: dereferencing type-punned pointer will break strict-aliasing rules dri_util.c:221: warning: dereferencing type-punned pointer will break strict-aliasing rules dri_util.c: In function `driCreateNewDrawable': dri_util.c:704: error: structure has no member named `screen' dri_util.c:724: error: structure has no member named `screen' dri_util.c:726: error: structure has no member named `screen' dri_util.c:728: error: structure has no member named `screen' dri_util.c:739: error: structure has no member named `screen' dri_util.c: In function `__driUtilCreateScreen': dri_util.c:1027: error: structure has no member named `screen' dri_util.c:1029: error: structure has no member named `next' make[5]: *** [dri_util.o] Error 1 make[5]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/xc/lib/GL/dri' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/xc/lib/GL' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/xc/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/xc' make[1]: *** [World] Error 2 make[1]: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/xc' make: *** [World] Error 2 make: Leaving directory `/home/fxkuehl/snapshots/build/HEAD/xc' I don't have time to look into it now. I'll get back to it tomorrow and look into it myself if it isn't fixed by then. Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Dri-devel mailing list [EMAIL
Re: [Dri-devel] Build fails
On Tue, 2003-12-09 at 23:26, Felix Khling wrote: Hi, I tried to compile the new dri trunk on freedesktop.org now. I checked out Mesa-newtree and set the MesaSrcDir correctly in host.def and ran make World. These are the last few lines of make output: I don't have time to look into it now. I'll get back to it tomorrow and look into it myself if it isn't fixed by then. I checked out and compiled dri trunk + Mesa-newtree successfully a couple of hours ago. -- Ronny V. Vindenes [EMAIL PROTECTED] --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI newmesa merge
On Tue, 2003-12-09 at 18:33, Luis R. Rodriguez wrote: This should probably go in a another e-mail thread but what sort of more tests are left before merging IGP patch into DRI cvs tree? As soon as I find the time, I intend to look at your additions to my patch and see about getting it in. Unless someone else beats me to it, of course. :) -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote: CVSROOT: /cvs/dri Module name: xc Repository: xc/xc/config/cf/ Changes by: [EMAIL PROTECTED] 03/12/09 14:21:04 Log message: move NormalLibExpat definition into OS specific config files that'll help the merge from/to XFree86 at a later stage. The build is still broken on FreeBSD. Would it be objected to if I make the static expatness optional depending on platform? I'd rather not be linking statically for our ports version of the DRI, anyway. What I'm trying right now is making an ExpatLibrary definition in Imake.tmpl that is used in the drivers build. It's overridden for non-FreeBSD in host.def. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 716] GLX applications/commands very slow on ATI rage128
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=716 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 18:13 --- Does it also happen with a local connection to a :0 display? There used to be a buglet where some code on the client side would insist on trying to connect to :0 no matter what DISPLAY contains, no idea whether this has ever been fixed. All displays are local. Also, I _always_ use only one display at one time. And I do not think changing the display number to 0 helps matters. As I have already pointed out, this problem appears for the r128 driver, not the tdfx driver. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Build fails
On Tue, 9 Dec 2003 22:39:15 + Alan Hourihane [EMAIL PROTECTED] wrote: This sounds to me like you are picking up a stale copy of glcore.h from somewhere. There shouldn't be a xc/lib/GL/include/GL/internal/glcore.h any more, it'll use the one from Mesanew in Mesa-newtree/include/GL/internal/glcore.h. Ok, I think the problem is that the snapshot build script copies DRI CVS over a XFree86 source tree which still has the old glcore.h in a different place. I'll try deleting the xc/lib/GL and xc/extras/Mesa subdirs before copying DRI CVS over. Alan. Thanks, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 716] GLX applications/commands very slow on ATI rage128
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=716 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 18:48 --- What Michel is saying is that glxinfo and glxgears by default try to open the display at :0 and then continue. I suspect your starting the tdfx DRI on :0 and your rage128 on :1. If you start rage128 on :0 and tdfx on :1 you'll see that the problem switches to the tdfx driver. This was a bug in glxinfo glxgears and has since been fixed. So upgrading to the CVS versions will remedy your problem. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote: On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote: CVSROOT:/cvs/dri Module name:xc Repository: xc/xc/config/cf/ Changes by: [EMAIL PROTECTED] 03/12/09 14:21:04 Log message: move NormalLibExpat definition into OS specific config files that'll help the merge from/to XFree86 at a later stage. The build is still broken on FreeBSD. Would it be objected to if I make the static expatness optional depending on platform? I'd rather not be linking statically for our ports version of the DRI, anyway. Can you explain what's broken in the FreeBSD build ? Also - Is expat available on all FreeBSD versions ? What I'm trying right now is making an ExpatLibrary definition in Imake.tmpl that is used in the drivers build. It's overridden for non-FreeBSD in host.def. Can you send a patch first ? Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI newmesa merge
Alan Hourihane wrote: I'm going to merge the newmesa branch to the trunk in a few moments. I've giving people a heads up that I'm going to delete the xc/extras/Mesa directory and insist on people checking out a copy of Mesa's newtree and people setting that in their xc/config/cf/host.def file to point to their checked out copy. What about having the Make process check out the appropriate version to a directory within the DRI build? That way, you can also force the Make to check out a specific tag of the Mesa tree, to control when changes are applied, or let it check out the HEAD of the branch. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 716] GLX applications/commands very slow on ATI rage128
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=716 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 18:55 --- (In reply to comment #15) What Michel is saying is that glxinfo and glxgears by default try to open the display at :0 and then continue. I suspect your starting the tdfx DRI on :0 and your rage128 on :1. That is right. If you start rage128 on :0 and tdfx on :1 you'll see that the problem switches to the tdfx driver. I never investigated that combination. This was a bug in glxinfo glxgears and has since been fixed. So upgrading to the CVS versions will remedy your problem. I hope so. Whats the bug fix number in http://www.xfree86.org/cvs/ changes.html ? -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 716] GLX applications/commands very slow on ATI rage128
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=716 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 19:09 --- That web page doesn't list all changes going back to the last release. Believe me - this problem has been fixed. And try switching, and you'll see that the tdfx driver does get the same problem. Please checkout the latest CVS and build it, and report back if you think there's still trouble. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, 2003-12-09 at 15:52, Alan Hourihane wrote: On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote: On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote: CVSROOT: /cvs/dri Module name: xc Repository: xc/xc/config/cf/ Changes by: [EMAIL PROTECTED] 03/12/09 14:21:04 Log message: move NormalLibExpat definition into OS specific config files that'll help the merge from/to XFree86 at a later stage. The build is still broken on FreeBSD. Would it be objected to if I make the static expatness optional depending on platform? I'd rather not be linking statically for our ports version of the DRI, anyway. Can you explain what's broken in the FreeBSD build ? Also - Is expat available on all FreeBSD versions ? First it dies with not finding expat.h. Adding EXPATINCLUDES to common/Makefile.in fixed that. Then it dies on -lexpat because expat wasn't built (even with HasExpat YES not being defined in FreeBSD.cf). expat is available in ports, and I feel pretty safe saying everyone ever using the DRI on FreeBSD will already have it installed (having already installed XFree86-4-libraries which depends on it). I've never heard a single complaint in my memory about HasExpat already being set unconditionally in FreeBSD.cf. What I'm trying right now is making an ExpatLibrary definition in Imake.tmpl that is used in the drivers build. It's overridden for non-FreeBSD in host.def. Can you send a patch first ? Alan. http://www.freedesktop.org/~anholt/dri-expatfix.diff Apoligies for the mess in it; there are some other changes in there. It's what I've just tested on FreeBSD and Linux, with the linking looking like it ended up right (ldd shows no libexpat on linux) Unless there's some compelling reason to have expat linked statically, I'll have to end up patching to fix linking in ports, which will be annoying. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 787] Driver is throwing bad mode in r200SetCliprects
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=787 --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 19:48 --- Can you try the latest XFree86 CVS ? -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, Dec 09, 2003 at 04:14:09PM -0800, Eric Anholt wrote: On Tue, 2003-12-09 at 15:52, Alan Hourihane wrote: On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote: On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote: CVSROOT:/cvs/dri Module name:xc Repository: xc/xc/config/cf/ Changes by: [EMAIL PROTECTED] 03/12/09 14:21:04 Log message: move NormalLibExpat definition into OS specific config files that'll help the merge from/to XFree86 at a later stage. The build is still broken on FreeBSD. Would it be objected to if I make the static expatness optional depending on platform? I'd rather not be linking statically for our ports version of the DRI, anyway. Can you explain what's broken in the FreeBSD build ? Also - Is expat available on all FreeBSD versions ? First it dies with not finding expat.h. Adding EXPATINCLUDES to common/Makefile.in fixed that. Then it dies on -lexpat because expat wasn't built (even with HasExpat YES not being defined in FreeBSD.cf). O.k. I've fixed the Imakefile. As for HasExpat YES, there's UseExpat which should default to YES because BuildXF86DRI is set. UseExpat should override it. expat is available in ports, and I feel pretty safe saying everyone ever using the DRI on FreeBSD will already have it installed (having already installed XFree86-4-libraries which depends on it). I've never heard a single complaint in my memory about HasExpat already being set unconditionally in FreeBSD.cf. I've got a FreeBSD 4.3 box, I'll check if expat is installed by default. What I'm trying right now is making an ExpatLibrary definition in Imake.tmpl that is used in the drivers build. It's overridden for non-FreeBSD in host.def. Can you send a patch first ? Alan. http://www.freedesktop.org/~anholt/dri-expatfix.diff Apoligies for the mess in it; there are some other changes in there. It's what I've just tested on FreeBSD and Linux, with the linking looking like it ended up right (ldd shows no libexpat on linux) Unless there's some compelling reason to have expat linked statically, I'll have to end up patching to fix linking in ports, which will be annoying. The problem of putting the StaticLibrary() bits back in host.def results in the build linking against the dynamic version when merged back into XFree86 at a later date. I'm trying to modify the OS cf files now so that we don't lose that functionality. So if you want to do #ifndef ExpatLibrary #define ExpatLibrary StaticLibrary($(BUILDLIBDIR),expat) #endif in the linux.cf instead of the host.def that's fine with me. That'll leave the FreeBSD and OpenBSD architectures linking dynamically. Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, Dec 09, 2003 at 04:54:24PM -0800, Eric Anholt wrote: On Tue, 2003-12-09 at 16:34, Alan Hourihane wrote: On Tue, Dec 09, 2003 at 04:14:09PM -0800, Eric Anholt wrote: On Tue, 2003-12-09 at 15:52, Alan Hourihane wrote: On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote: On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote: CVSROOT:/cvs/dri Module name:xc Repository: xc/xc/config/cf/ Changes by: [EMAIL PROTECTED] 03/12/09 14:21:04 Log message: move NormalLibExpat definition into OS specific config files that'll help the merge from/to XFree86 at a later stage. The build is still broken on FreeBSD. Would it be objected to if I make the static expatness optional depending on platform? I'd rather not be linking statically for our ports version of the DRI, anyway. Can you explain what's broken in the FreeBSD build ? Also - Is expat available on all FreeBSD versions ? First it dies with not finding expat.h. Adding EXPATINCLUDES to common/Makefile.in fixed that. Then it dies on -lexpat because expat wasn't built (even with HasExpat YES not being defined in FreeBSD.cf). O.k. I've fixed the Imakefile. As for HasExpat YES, there's UseExpat which should default to YES because BuildXF86DRI is set. UseExpat should override it. But BuildExpat is (UseExpat !HasExpat), right? Yes. Missed that essential piece. I'd moved straight down to see the #if UseExpat furthur down X11.tmpl. expat is available in ports, and I feel pretty safe saying everyone ever using the DRI on FreeBSD will already have it installed (having already installed XFree86-4-libraries which depends on it). I've never heard a single complaint in my memory about HasExpat already being set unconditionally in FreeBSD.cf. I've got a FreeBSD 4.3 box, I'll check if expat is installed by default. If you mean in the base install, no, it isn't (well, except as libbsdxml, but it's renamed for a reason). But you can't build the DRI from a base FreeBSD install, last I knew of; you first need to install XFree86. If you are doing it properly on FreeBSD that means using ports, which means XFree86-4-libraries which depends on libexpat. If people install XFree86 from source, I hope XFree86 is installing its libexpat in the right place, but I don't care about that too much. Their system is probably going to end up broken in odd ways when they try to use ports after that anyway. O.k. I'll defer to your decision on that. What I'm trying right now is making an ExpatLibrary definition in Imake.tmpl that is used in the drivers build. It's overridden for non-FreeBSD in host.def. Can you send a patch first ? Alan. http://www.freedesktop.org/~anholt/dri-expatfix.diff Apoligies for the mess in it; there are some other changes in there. It's what I've just tested on FreeBSD and Linux, with the linking looking like it ended up right (ldd shows no libexpat on linux) Unless there's some compelling reason to have expat linked statically, I'll have to end up patching to fix linking in ports, which will be annoying. The problem of putting the StaticLibrary() bits back in host.def results in the build linking against the dynamic version when merged back into XFree86 at a later date. I'm trying to modify the OS cf files now so that we don't lose that functionality. So if you want to do #ifndef ExpatLibrary #define ExpatLibrary StaticLibrary($(BUILDLIBDIR),expat) #endif in the linux.cf instead of the host.def that's fine with me. That'll leave the FreeBSD and OpenBSD architectures linking dynamically. So Linux has to have it linked statically in XFree86, too? Not seeing the reason for that, but OK. Actually, I've had a rethink about this. Leave it in host.def for now as you've got it. We may need to revisit it later. Go ahead and commit the patch you've got. Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Tue, 2003-12-09 at 16:34, Alan Hourihane wrote: On Tue, Dec 09, 2003 at 04:14:09PM -0800, Eric Anholt wrote: On Tue, 2003-12-09 at 15:52, Alan Hourihane wrote: On Tue, Dec 09, 2003 at 03:05:57PM -0800, Eric Anholt wrote: On Tue, 2003-12-09 at 14:21, Alan Hourihane wrote: CVSROOT: /cvs/dri Module name: xc Repository: xc/xc/config/cf/ Changes by: [EMAIL PROTECTED] 03/12/09 14:21:04 Log message: move NormalLibExpat definition into OS specific config files that'll help the merge from/to XFree86 at a later stage. The build is still broken on FreeBSD. Would it be objected to if I make the static expatness optional depending on platform? I'd rather not be linking statically for our ports version of the DRI, anyway. Can you explain what's broken in the FreeBSD build ? Also - Is expat available on all FreeBSD versions ? First it dies with not finding expat.h. Adding EXPATINCLUDES to common/Makefile.in fixed that. Then it dies on -lexpat because expat wasn't built (even with HasExpat YES not being defined in FreeBSD.cf). O.k. I've fixed the Imakefile. As for HasExpat YES, there's UseExpat which should default to YES because BuildXF86DRI is set. UseExpat should override it. But BuildExpat is (UseExpat !HasExpat), right? expat is available in ports, and I feel pretty safe saying everyone ever using the DRI on FreeBSD will already have it installed (having already installed XFree86-4-libraries which depends on it). I've never heard a single complaint in my memory about HasExpat already being set unconditionally in FreeBSD.cf. I've got a FreeBSD 4.3 box, I'll check if expat is installed by default. If you mean in the base install, no, it isn't (well, except as libbsdxml, but it's renamed for a reason). But you can't build the DRI from a base FreeBSD install, last I knew of; you first need to install XFree86. If you are doing it properly on FreeBSD that means using ports, which means XFree86-4-libraries which depends on libexpat. If people install XFree86 from source, I hope XFree86 is installing its libexpat in the right place, but I don't care about that too much. Their system is probably going to end up broken in odd ways when they try to use ports after that anyway. What I'm trying right now is making an ExpatLibrary definition in Imake.tmpl that is used in the drivers build. It's overridden for non-FreeBSD in host.def. Can you send a patch first ? Alan. http://www.freedesktop.org/~anholt/dri-expatfix.diff Apoligies for the mess in it; there are some other changes in there. It's what I've just tested on FreeBSD and Linux, with the linking looking like it ended up right (ldd shows no libexpat on linux) Unless there's some compelling reason to have expat linked statically, I'll have to end up patching to fix linking in ports, which will be annoying. The problem of putting the StaticLibrary() bits back in host.def results in the build linking against the dynamic version when merged back into XFree86 at a later date. I'm trying to modify the OS cf files now so that we don't lose that functionality. So if you want to do #ifndef ExpatLibrary #define ExpatLibrary StaticLibrary($(BUILDLIBDIR),expat) #endif in the linux.cf instead of the host.def that's fine with me. That'll leave the FreeBSD and OpenBSD architectures linking dynamically. So Linux has to have it linked statically in XFree86, too? Not seeing the reason for that, but OK. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] DRI newmesa merge
On Tue, 2003-12-09 at 10:29, Brian Paul wrote: Alan Hourihane wrote: On Tue, Dec 09, 2003 at 09:58:44AM -0800, Jon Smirl wrote: --- Alan Hourihane [EMAIL PROTECTED] wrote: So Mesa/newtree is going to be the master copy of the dri drivers, including the ones in mesa/dri/drivers? I'm all for that after doing the merge a couple of times. Yes. I've giving people a heads up that I'm going to delete the xc/extras/Mesa directory and insist on people checking out a copy of Mesa's newtree and people setting that in their xc/config/cf/host.def file to point to their Is this going to cause a lot of anon cvs load that currently is on freedesktop.org to revert back to sf.net (with all of it's problems)? Does mesa need to move cvs to freedesktop now? I guess that's Brian's call. I don't believe he had intentions to move it. I think SourceForge has fixed the CVS problems of times gone by. If SF's CVS causes problems, I'm OK with moving Mesa to freedesktop. It would make me happy. 5 out of my last 7 tries to cvs up anonymously just now failed, and of course my patch for icc didn't make it in due to the mirroring. I think this is going to get more annoying as we've moved the DRI driver development to Mesa. Plus, we'd get cvsup if we moved. I think the switchover this time wouldn't be so horribly painful, as I've learned the lesson to just make the switch and bring peoples' changes over by hand instead of trying to get a clean snapshot of the latest tree. Might also be an opportunity to make Mesa-newtree Mesa again :-) -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
