Re: Improve state emitting for ipers
On Mon, 2004-09-20 at 15:00, Roland Scheidegger wrote: Eric Anholt wrote: The attached patch removes the mandatory emits of all state which were happening after each cmdbuf flush. Instead, we set a flag after a cmdbuf flush saying save the state at the next unlock, which means memcpying the state atoms off. When we actually see the context get lost, then we back up and restore state -- make a new cmdbuf, dirty all state, emit it, flush it, then put the old cmdbuf back. I like it ;-). I thought the locking really to be inefficient (but never did anything against it...). It was that state emit to ensure lost-context recovery that was the real killer. While working on it, I thought, Man, all of this lock/unlocking going on has to have bad effects on performance. So I made (UN)LOCK_HARDWARE into inlines, and they were only around .01% of CPU time according to oprofile. So I'm not too worried about locking. One thing that I had talked about with Keith when working on the race fixes was the possibility of making the DRI locks recursive. This would let us be lazier about coding sometimes, but would also make DRI modules integration into the server (for hardware indirect) easier. While recursive acquires are more expensive, it looks like the locking costs aren't really an issue. I also removed the dirty/clean state lists and made a single one. The reasoning was that we have to walk the entire list on emit (and twice when the all-dirty is set) anyway, and I felt that this was cleaner. It was not always that inefficient in r200EmitState, only since the fixed emit order was introduced (and still no one understands why the fixed order is needed). Didn't seem to make a performance difference though (profiling showed it really didn't use much cpu time). Yeah, it was clear that we used to emit in whatever order, and that would have been nicer. At this point I'm seeing about 5% CPU time in EmitState for ipers, which seems pretty hefty for such a small bit of code, but I didn't see much obvious for improvement. Fixed order (at least within limits) being required certainly makes sense to me. I've found that docs sometimes say things like, Writes to this register take no effect if bits X of register Y are not set to Z. It may be that those dependencies were just not recorded. This gets about a 5% speedup for me in ipers (which I wish was more accurate in its reporting), and doesn't touch glxgears. I didn't have any interesting apps besides glxgears handy to benchmark with. Any thoughts on this? If people think it's a good idea, I'll do it for radeon as well. I certainly think it's a good idea. However, I still think it should be possible to lock across multiple buffers, to make it possible to emit larger numbers of vertices at once (for instance for things like glDrawElements), which, as far as I understand, just cannot work if you're restricted to one buffer. Multiples of which buffers are you talking about here? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://freedesktop.org/bugzilla/show_bug.cgi?id=1220 --- Additional Comments From [EMAIL PROTECTED] 2004-09-21 00:25 --- It seems this is a regression over 6.7. The VT switch doesn't POST the chip as expected. Furthermore, my M7 just hangs if I launch a second X session. -- Configure bugmail: https://freedesktop.org/bugzilla/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: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://freedesktop.org/bugzilla/show_bug.cgi?id=1220 --- Additional Comments From [EMAIL PROTECTED] 2004-09-21 02:26 --- hi, you have to start it in background or it won't work, but there is a code fix, which is maybe or hopefully implemented i CVS. this was send to me by Fabrice Bellet, which works for me too: - E-Mail from Fabrice Bellet -- I use xorg CVS, so I patched the file : xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c and I recompiled the driver radeon_drv.o in this directory. Index: radeon_driver.c === RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v retrieving revision 1.19 diff -u -r1.19 radeon_driver.c --- radeon_driver.c 25 Aug 2004 00:30:41 - 1.19 +++ radeon_driver.c 16 Sep 2004 10:51:23 - @@ -4562,7 +4562,9 @@ } #endif +#if 0 RADEONSetFBLocation(pScrn); +#endif if (!fbScreenInit(pScreen, info-FB, pScrn-virtualX, pScrn-virtualY, But I'm not sure at all, that this is the correct fix. Best wishes, -- fabrice - E-Mail from Fabrice Bellet -- thx to Fabrice for the fix, it's the right one I hope some developer implement this in the CVS tree, if it's not done yet! -- Configure bugmail: https://freedesktop.org/bugzilla/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: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM radeon i2c support and GPL
I picked a very simple piece of code to start out with as a test case. The I2C code is only a hundred lines and could be rewritten. But what's the point, BSD doesn't have Linux's I2C driver system. This code has no value anywhere but on Linux. That's not a statement thats safe to make. BSD (or any other OS that XOrg supports) may not have Linux's I2C driver system. TODAY. What if, next week, BSD gets such a beast, or HP-UX does, or Solaris or whatever. Maybe now that code that is currently only of value on Linux is of value on a broad range of systems. Now you have the potential for a broad range of non-GPL systems to be dependent on GPL code, which is, after all, the point I think the original strawman paper was addressing. If XOrg is trying to be license agnostic, it is going to need to stay away from the GPL. The current MIT style license seems to be quite acceptable to GPL-centric projects. However, the reverse is not (always) true. Kean --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM radeon i2c support and GPL
Le mardi 21 septembre 2004 00:58 -0700, Kean Johnston a crit : I picked a very simple piece of code to start out with as a test case. The I2C code is only a hundred lines and could be rewritten. But what's the point, BSD doesn't have Linux's I2C driver system. This code has no value anywhere but on Linux. That's not a statement thats safe to make. BSD (or any other OS that XOrg supports) may not have Linux's I2C driver system. TODAY. What if, next week, BSD gets such a beast, or HP-UX does, or Solaris or whatever. Maybe now that code that is currently only of value on Linux is of value on a broad range of systems. Then the xorg code will be rewritten in a platform-agnostic way with a more permissive license. Or do you believe you can write now some code that will work as-is with yet unwritten platform implementations? Since the code *will* need to be adapted then, the licensing can be reviewed at that time too. That's the point people tried to make, I think. Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: DRM radeon i2c support and GPL
Le mar 21/09/2004 09:58, Kean Johnston a crit : I picked a very simple piece of code to start out with as a test case. The I2C code is only a hundred lines and could be rewritten. But what's the point, BSD doesn't have Linux's I2C driver system. This code has no value anywhere but on Linux. That's not a statement thats safe to make. BSD (or any other OS that XOrg supports) may not have Linux's I2C driver system. TODAY. What if, next week, BSD gets such a beast, or HP-UX does, or Solaris or whatever. Maybe now that code that is currently only of value on Linux is of value on a broad range of systems. My understanding is that if/when BSDs (and others) implement an I2C system, it'll probably be compatible with the Linux one from the userspace side (i.e. the syscalls will have the same semantics) but certainly not from the kernel side: there's not point for them to be compatible with the Linux architecture as they can't import its drivers. I don't the DRM drivers, but if they use I2C from the kernel side there's not point in licensing that code for multiplatform. Xav --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://freedesktop.org/bugzilla/show_bug.cgi?id=1220 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-09-21 03:40 --- Ah, I'm using radeonfb if that matters, I'll try without later on. -- Configure bugmail: https://freedesktop.org/bugzilla/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: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM radeon i2c support and GPL
On Maw, 2004-09-21 at 08:58, Kean Johnston wrote: That's not a statement thats safe to make. BSD (or any other OS that XOrg supports) may not have Linux's I2C driver system. TODAY. What if, next week, BSD gets such a beast, or HP-UX does, or Well they can't use the low level Linux code anyway, because its GPL licensed and likely to stay that way. If XOrg is trying to be license agnostic, it is going to need to stay away from the GPL. The current MIT style license seems to be quite acceptable to GPL-centric projects. However, the reverse is not (always) true. Thats a shame. I guess its time to take DRI back out of the Xorg tree if this kind of extremist view is the preferred one, or just keep the kernel code in the Linux kernel and remove it from X.org ? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
XComposite and GLX
I have began to study the GLX code, to see the best way of getting Composite extension to support redirection of GLX. I will concentrate at first on server side code (software rendering). this will be a key to go afterwards to support DRI. I would like to know if there is someone has began this before or plan to work in it, so that we could share ideas! please use this thread to discuss this issue. -- Amir Bukhari [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM radeon i2c support and GPL
On Mon, 20 Sep 2004 13:38:15 -0400, Adam Jackson [EMAIL PROTECTED] wrote: On Monday 20 September 2004 12:59, Jon Smirl wrote: On Mon, 20 Sep 2004 12:29:30 -0400, Adam Jackson [EMAIL PROTECTED] wrote: License compatibility != OS compatibility, please don't conflate the two. X runs on more than just Linux, and source is distributed as an aggregate. If The Linux DRM driver does not run anywhere but on Linux. The GPL code is isolated to the Linux DRM driver. I wonder if DRM isn't GPL already by accident. DRM has been included in the Linux kernel under the GPL license. DRM has also accepted many bug patches back from the kernel people. If a fork had occurred between kernel and DRM it would be clear than one fork is GPL and one BSD. But the code never forked. Since there is only one code base and that code base has been released GPL via the kernel, so we may have inadvertently made DRM GPL. I would read it as since the code never forked, we're still BSD. Inclusion is not conversion, in this case. All the copyright statements in the DRM source (excluding your recent commit) specify BSD licenses. If the bug-fixers wanted their changes to apply under the GPL they should have indicated that by changing the copyright statement at the top of the file. The aggregate kernel is GPL, yes, but that doesn't mean all the components are. ppp_deflate.c has gotten fixes from kernel people too, but it's still BSD-licensed. I've never understood why the aggregate X (which includes some non MIT licensed code) can't have multiple licenses. The linux kernel does; other projects do. as long as it's properly labled in the code. People use X on linux. people run gnome on BSD. technically X and BSD have slightly different licenes too. Alex I'd feel a whole lot better about the licensing if BSD and Linux DRM were split into two repositories. That still wouldn't address the issue of inclusion in Xorg, unless Xorg were to only ship with the BSD DRM. And it would probably demote the BSD OSes to fifth-class citizen status. Can't say as I'm a fan of that idea. it's really that big of a deal, ask the author of the GPL code to allow you to add it to DRM under an X-friendly license. This is a waste of time. I know that some of the authors have a GPL or die attitude towards device driver code. Reimplementing code that the original author doesn't want to relicense is nothing new under the sun (freeglut). I believe that splintering the code base into universal and GPL versions is a bad idea, because it means any code in the GPL version that someone wants to use in the universal version has to be written twice - inevitably diverging the two trees and creating the sort of cross-merge hell we're trying to get away from. If we're going to waste time like this, we might as well do it once, up front, and be done with it. - ajax ___ xorg mailing list [EMAIL PROTECTED] http://freedesktop.org/mailman/listinfo/xorg --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM radeon i2c support and GPL
Alan, Please read, understand and comment on the license policy strawman I posted both to dri-devel and the xorg list. It is a strawman, a first draft, and as I understand my intent, is specifically intended to make it possible to permit such situations. Whether it actually says that clearly, is, of course possibly questionable ;-). Such policy can only be set by the community of course, and that requires discussion. I also expect that as the releases become more modular, this situation also becomes more modular and less of an issue in any case. I personally prefer that kernel stuff be integrated in the kernel, but that is because I always find having more than one version is usually error prone (the same reasons we're trying to get things like freetype, xterm, fontconfig/xft all from upstream modular sources, rather than the current integration of stale bits). - Jim Subject: Re: DRM radeon i2c support and GPL From: Alan Cox [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Jon Smirl [EMAIL PROTECTED], Discuss issues related to the xorg tree [EMAIL PROTECTED], DRI Devel [EMAIL PROTECTED] Date: Tue, 21 Sep 2004 10:48:05 +0100 On Maw, 2004-09-21 at 08:58, Kean Johnston wrote: That's not a statement thats safe to make. BSD (or any other OS that XOrg supports) may not have Linux's I2C driver system. TODAY. What if, next week, BSD gets such a beast, or HP-UX does, or Well they can't use the low level Linux code anyway, because its GPL licensed and likely to stay that way. If XOrg is trying to be license agnostic, it is going to need to stay away from the GPL. The current MIT style license seems to be quite acceptable to GPL-centric projects. However, the reverse is not (always) true. Thats a shame. I guess its time to take DRI back out of the Xorg tree if this kind of extremist view is the preferred one, or just keep the kernel code in the Linux kernel and remove it from X.org ? --__--__-- Message: 10 Subject: XComposite and GLX From: Amir Bukhari [EMAIL PROTECTED] To: dri-devel [EMAIL PROTECTED], Xorg [EMAIL PROTECTED] Date: Tue, 21 Sep 2004 15:54:25 +0200 I have began to study the GLX code, to see the best way of getting Composite extension to support redirection of GLX. I will concentrate at first on server side code (software rendering). this will be a key to go afterwards to support DRI. I would like to know if there is someone has began this before or plan to work in it, so that we could share ideas! please use this thread to discuss this issue. -- Amir Bukhari [EMAIL PROTECTED] --__--__-- Message: 11 Date: Tue, 21 Sep 2004 10:24:11 -0400 From: Alex Deucher [EMAIL PROTECTED] Reply-To: Alex Deucher [EMAIL PROTECTED] To: Discuss issues related to the xorg tree [EMAIL PROTECTED] Subject: Re: DRM radeon i2c support and GPL Cc: Jon Smirl [EMAIL PROTECTED], [EMAIL PROTECTED] On Mon, 20 Sep 2004 13:38:15 -0400, Adam Jackson [EMAIL PROTECTED] wrote: On Monday 20 September 2004 12:59, Jon Smirl wrote: On Mon, 20 Sep 2004 12:29:30 -0400, Adam Jackson [EMAIL PROTECTED] wrote: License compatibility != OS compatibility, please don't conflate the two. X runs on more than just Linux, and source is distributed as an aggregate. If The Linux DRM driver does not run anywhere but on Linux. The GPL code is isolated to the Linux DRM driver. I wonder if DRM isn't GPL already by accident. DRM has been included in the Linux kernel under the GPL license. DRM has also accepted many bug patches back from the kernel people. If a fork had occurred between kernel and DRM it would be clear than one fork is GPL and one BSD. But the code never forked. Since there is only one code base and that code base has been released GPL via the kernel, so we may have inadvertently made DRM GPL. I would read it as since the code never forked, we're still BSD. Inclusion is not conversion, in this case. All the copyright statements in the DRM source (excluding your recent commit) specify BSD licenses. If the bug-fixers wanted their changes to apply under the GPL they should have indicated that by changing the copyright statement at the top of the file. The aggregate kernel is GPL, yes, but that doesn't mean all the components are. ppp_deflate.c has gotten fixes from kernel people too, but it's still BSD-licensed. I've never understood why the aggregate X (which includes some non MIT licensed code) can't have multiple licenses. The linux kernel does; other projects do. as long as it's properly labled in the code. People use X on linux. people run gnome on BSD. technically X and BSD have slightly different licenes too. Alex I'd feel a whole lot better about the licensing if BSD and Linux DRM were split into two repositories. That still wouldn't address the issue of inclusion in Xorg, unless Xorg were to
Re: DRM radeon i2c support and GPL
On Tuesday 21 September 2004 10:24, Alex Deucher wrote: On Mon, 20 Sep 2004 13:38:15 -0400, Adam Jackson [EMAIL PROTECTED] wrote: I would read it as since the code never forked, we're still BSD. Inclusion is not conversion, in this case. All the copyright statements in the DRM source (excluding your recent commit) specify BSD licenses. If the bug-fixers wanted their changes to apply under the GPL they should have indicated that by changing the copyright statement at the top of the file. The aggregate kernel is GPL, yes, but that doesn't mean all the components are. ppp_deflate.c has gotten fixes from kernel people too, but it's still BSD-licensed. I've never understood why the aggregate X (which includes some non MIT licensed code) can't have multiple licenses. The linux kernel does; other projects do. as long as it's properly labled in the code. People use X on linux. people run gnome on BSD. technically X and BSD have slightly different licenes too. I don't see why it can't either, besides that we've never formally stated that that's okay. If you're not going to link the GPL-licensed bits with a non-GPL kernel, then having GPL bits in the tree isn't a big deal. My strong preference is to minimize GPL code in the tree, for the usual contamination reasons. But either way, we need a formally stated policy. - ajax pgpVG6CNrXMr1.pgp Description: PGP signature
Re: Design for setting video modes, ownership of sysfs attributes
On Tue, 21 Sep 2004 14:45:07 +0200, Pavel Machek [EMAIL PROTECTED] wrote: Hi! 1) user owns graphics devices 2) user sets mode with string (or similar) format using ioctl common to all drivers. 3) driver is locked to prevent multiple mode sets 4) common code takes this string and does a hotplug event with it. I though this was Driver decides to either do it itself in kernel, or call userspace helper if that would be too complex. The driver almost always needs to go to user space to get the file of mode line overrides that the user can create. But there is nothing stopping you from building everything in the kernel. I'd just rather not have 100K of resident code waiting around for something that doesn't occur very often. For the radeon sample I'm working on I have moved everything to user space except for a couple of small helper functions that directly play with the registers. Note that all mode setting in X occurs completely in user space so you can't argue that it can't be done. How are errors going to be communicated in this scheme? I can cat the sysfs mode variable to get a status. Is there a good way to do this without polling? I'd say that write() to that sysfs file can simply return error. See echo disk /sys/power/state, it returns error if transition failed. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1428] drmAddMap failed with latest drm CVS
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://freedesktop.org/bugzilla/show_bug.cgi?id=1428 --- Additional Comments From [EMAIL PROTECTED] 2004-09-21 08:58 --- This should be fixed in CVS now -- Configure bugmail: https://freedesktop.org/bugzilla/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: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM radeon i2c support and GPL
On Maw, 2004-09-21 at 16:19, Jim Gettys wrote: Please read, understand and comment on the license policy strawman I posted both to dri-devel and the xorg list. Oh I did, don't take my response as anything but throwing up the logical conclusion to that policy. I'm not in favour of that approach. Such policy can only be set by the community of course, and that requires discussion. Historically X core code which is (L)GPL has been rejected. That has always made sense as the effects are often bizarre like probably not being able to use the vnc driver and trident driver together even though they share an author. I don't believe X should change on that issue. The question is one of additional programs that come with X - that is what the Linux DRI kernel module really is. Currently almost everyone in the X world is using some GPL software with their X server, it just happens to be in a different tarball/rpm/dpkg/... I also expect that as the releases become more modular, this situation also becomes more modular and less of an issue in any case. Agreed --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Improve state emitting for ipers
Am Montag, 20. September 2004 23:14 schrieb Eric Anholt: On Mon, 2004-09-20 at 12:58, Dieter Ntzel wrote: Am Montag, 20. September 2004 21:52 schrieb Dieter Ntzel: Am Sonntag, 19. September 2004 11:21 schrieb Eric Anholt: The attached patch removes the mandatory emits of all state which were happening after each cmdbuf flush. Instead, we set a flag after a cmdbuf flush saying save the state at the next unlock, which means memcpying the state atoms off. When we actually see the context get lost, then we back up and restore state -- make a new cmdbuf, dirty all state, emit it, flush it, then put the old cmdbuf back. I also removed the dirty/clean state lists and made a single one. The reasoning was that we have to walk the entire list on emit (and twice when the all-dirty is set) anyway, and I felt that this was cleaner. It also fixed some bad cmdbufs that were happening for me (drmCommandWrite: -22) with the CVS code. This gets about a 5% speedup for me in ipers (which I wish was more accurate in its reporting), Do you think it's only 5% for you? It is GREAT. Ipers is back when not faster ever on my system ;-) 31 fps, 825.000 from ~25, ~660.000 = 24% But got progs/demos IperS V1.0 Written by David Bucciarelli ([EMAIL PROTECTED]) Mesa: software DXTn compression/decompression available drmCommandWrite: -22 drmRadeonCmdBuffer: -22 (exiting) [1]Exitcode 234 ./ipers when I cycle through the drawing modes (t/b/n) during wire frame (p). -Dieter And this is a new effect? Don't know. I don't remember that it happened any time before. Interesting -- I'll have to try this out when I get home. Good to hear the generally good news, though. I'll run Viewperf-7.1.1, now ;-) -Dieter --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1428] drmAddMap failed with latest drm CVS
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://freedesktop.org/bugzilla/show_bug.cgi?id=1428 --- Additional Comments From [EMAIL PROTECTED] 2004-09-21 12:08 --- Yes confirmed, works again. This bug can be closed. Many thanks :) -- Configure bugmail: https://freedesktop.org/bugzilla/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: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Improve state emitting for ipers
Am Dienstag, 21. September 2004 00:00 schrieb Roland Scheidegger:
Eric Anholt wrote:
The attached patch removes the mandatory emits of all state which were
happening after each cmdbuf flush. Instead, we set a flag after a
cmdbuf flush saying save the state at the next unlock, which means
memcpying the state atoms off. When we actually see the context get
lost, then we back up and restore state -- make a new cmdbuf, dirty
all state, emit it, flush it, then put the old cmdbuf back.
I like it ;-). I thought the locking really to be inefficient (but never
did anything against it...).
I also
removed the dirty/clean state lists and made a single one. The
reasoning was that we have to walk the entire list on emit (and twice
when the all-dirty is set) anyway, and I felt that this was cleaner.
It was not always that inefficient in r200EmitState, only since the
fixed emit order was introduced (and still no one understands why the
fixed order is needed). Didn't seem to make a performance difference
though (profiling showed it really didn't use much cpu time).
This gets about a 5% speedup for me in ipers (which I wish was more
accurate in its reporting), and doesn't touch glxgears. I didn't have
any interesting apps besides glxgears handy to benchmark with. Any
thoughts on this? If people think it's a good idea, I'll do it for
radeon as well.
I certainly think it's a good idea.
However, I still think it should be possible to lock across multiple
buffers, to make it possible to emit larger numbers of vertices at once
(for instance for things like glDrawElements), which, as far as I
understand, just cannot work if you're restricted to one buffer.
Is this related?
http://marc.theaimsgroup.com/?l=dri-develm=108350714917936w=2
-Dieter
? depend
Index: r200_pixel.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_pixel.c,v
retrieving revision 1.6
diff -u -r1.6 r200_pixel.c
--- r200_pixel.c 27 Apr 2004 18:37:13 - 1.6
+++ r200_pixel.c 2 May 2004 14:01:47 -
@@ -287,7 +287,7 @@
static void do_draw_pix( GLcontext *ctx,
GLint x, GLint y, GLsizei width, GLsizei height,
GLint pitch,
- const void *pixels,
+ int src_offset,
GLuint planemask)
{
r200ContextPtr rmesa = R200_CONTEXT(ctx);
@@ -297,7 +297,6 @@
int i;
int blit_format;
int size;
- int src_offset = r200GartOffsetFromVirtual( rmesa, pixels );
int src_pitch = pitch * rmesa-r200Screen-cpp;
if (R200_DEBUG DEBUG_PIXEL)
@@ -429,14 +428,20 @@
do_draw_pix( ctx, x, y, width, height, pitch, pixels, planemask );
return GL_TRUE;
}
- else if (0)
+ else
{
/* Pixels is in regular memory -- get dma buffers and perform
* upload through them.
*/
+ struct r200_dma_region region;
+ memset(region, 0, sizeof(region));
+ r200AllocDmaRegion( rmesa, region, size, 1024 );
+ memcpy(region.address + region.start, pixels, size);
+
+ do_draw_pix( ctx, x, y, width, height, pitch, GET_START(region), planemask );
+
+ r200ReleaseDmaRegion(rmesa,region,__FUNCTION__);
}
- else
- return GL_FALSE;
}
static void
[Bug 1428] drmAddMap failed with latest drm CVS
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://freedesktop.org/bugzilla/show_bug.cgi?id=1428 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-09-21 12:20 --- fixed in cvs -- Configure bugmail: https://freedesktop.org/bugzilla/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: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
exception testing in r200 driver
_mesa_test_os_sse_exception, executed upon start of any OpenGL application raises SIGFPE. Normally this is not a problem, applications continue to execute normally. However when using the jogl OpenGL Java binding programs exit. I tried both with Java 1.4 from Sun and sablevm. Philipp --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] - likely compatibility w rv360?
Hi. I am very happy to see that the more recent Radeons are being looked into. A few questions: 1. Is the rv360 (9600xt) close enough to the developers hardware to a) benefit from the 2d improvements already made w.r.t. CP acceleration b) be of any use for testing purposes If the answer to a) is don't know I'll be happy to try. But I'll skip it if somebody says don't bother. 2. Should I assume that you guys will stick to 6.7.0 until a more uptodate binary driver is available? 3. Anyone tried to patch 6.8.1 with the 2D patch? and finally: 4. Is the 9250 supported by the current dri code? Thanks, Dag B --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Improve state emitting for ipers
Dieter Nützel wrote: This gets about a 5% speedup for me in ipers (which I wish was more accurate in its reporting), and doesn't touch glxgears. I didn't have any interesting apps besides glxgears handy to benchmark with. Any thoughts on this? If people think it's a good idea, I'll do it for radeon as well. I certainly think it's a good idea. However, I still think it should be possible to lock across multiple buffers, to make it possible to emit larger numbers of vertices at once (for instance for things like glDrawElements), which, as far as I understand, just cannot work if you're restricted to one buffer. Is this related? http://marc.theaimsgroup.com/?l=dri-develm=108350714917936w=2 Not really. This is a patch to accelerate glDrawPixels, not glDrawElements. I'll hopefully submit an improved version one day, when I have incorporated suggestions Ian and Michel gave me on irc. Stephane --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
On Tue, 21 Sep 2004 10:18:01 -0800, Dag Bakke [EMAIL PROTECTED] wrote: Hi. I am very happy to see that the more recent Radeons are being looked into. A few questions: 1. Is the rv360 (9600xt) close enough to the developers hardware to a) benefit from the 2d improvements already made w.r.t. CP acceleration yes b) be of any use for testing purposes yes If the answer to a) is don't know I'll be happy to try. But I'll skip it if somebody says don't bother. 2. Should I assume that you guys will stick to 6.7.0 until a more uptodate binary driver is available? most developers will be working from xorg and mesa cvs. 3. Anyone tried to patch 6.8.1 with the 2D patch? yes. a patch is available on the r300 website: http://r300.sourceforge.net/ and finally: 4. Is the 9250 supported by the current dri code? it should be. Probably just need to add the pci id if it's not there already. Alex Thanks, Dag B --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Improve state emitting for ipers
Am Montag, 20. September 2004 22:13 schrieb Ian Romanick:
Eric Anholt wrote:
This gets about a 5% speedup for me in ipers (which I wish was more
accurate in its reporting), and doesn't touch glxgears. I didn't have
any interesting apps besides glxgears handy to benchmark with.
I should be able to give it a spin on viewperf sometime this week...
I am running viewperf-7.1.1, now.
Have viewperf-8.0.1, too.
Ian can you please check why we get empty/black windows with SMP on viewperf
for some tests (e.g. 'ugs').
You have to compile with '-DMP'.
# Add -DMP to the following line to build a multithreaded viewperf
DEFINES = -DXWINDOWS -DSEARCHPATH -DLINUX -DPNG -DMP
And modified 'EnvLINUX.c' version.
Add this:
/**
*
* GetNumProcessors - return number of processor on system
*
* Description:
* For MP execution, then number of processors is used for identification of
* of the number of graphics threads to exploit.
*
* Returns:
* integet number of processors
*
* Side Effects:
* none
*
* Errors:
* no errors, if function fails the string 1 is returned
*
* Revision History:
*Initial Release
*
*/
int
GetNumProcessors()
{
return (2);
}
---
Second,
there is something wrong (maybe together with latest KDE 3.3.0 on my SuSE 9.0)
because in _all_ texture modes there is superimposed 'konsole' output in
every ~/results/*/*.png images.
See attached example (proe02.png).
Cheers,
Dieter
attachment: proe02.png
Re: [r300] - likely compatibility w rv360?
On Maw, 2004-09-21 at 19:18, Dag Bakke wrote: 1. Is the rv360 (9600xt) close enough to the developers hardware to a) benefit from the 2d improvements already made w.r.t. CP acceleration b) be of any use for testing purposes The 6.8.0 server supports 2D acceleration up to the PCI Express cards like the V5100. I don't personally know which PCI Express are tested beyond the M300. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Improve state emitting for ipers
Eric Anholt wrote: Yeah, it was clear that we used to emit in whatever order, and that would have been nicer. At this point I'm seeing about 5% CPU time in EmitState for ipers, which seems pretty hefty for such a small bit of code, but I didn't see much obvious for improvement. That's indeed quite a bit. It's not enough though to really be concerned about it at the moment imho. Fixed order (at least within limits) being required certainly makes sense to me. I've found that docs sometimes say things like, Writes to this register take no effect if bits X of register Y are not set to Z. It may be that those dependencies were just not recorded. It's just suspicious because there seems to be nothing at all about it in the documentation (well don't ask me, I don't have any...). I certainly think it's a good idea. However, I still think it should be possible to lock across multiple buffers, to make it possible to emit larger numbers of vertices at once (for instance for things like glDrawElements), which, as far as I understand, just cannot work if you're restricted to one buffer. Multiples of which buffers are you talking about here? Well, I'm not really sure about it. But it looked to me like there might be problems wrt context switching if your vertex data doesn't fit into one vertex buffer (basically you fill up one buffer, another app another one, and I'm not too sure offsets and such will be correct). Well maybe I'm wrong. Roland --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Design for setting video modes, ownership of sysfs attributes
On Maw, 2004-09-21 at 16:56, Jon Smirl wrote: Driver decides to either do it itself in kernel, or call userspace helper if that would be too complex. It is The driver almost always needs to go to user space to get the file of mode line overrides that the user can create. But there is nothing stopping you from building everything in the kernel. For random PC cards this is true. If you take something like the voodoo1 which essentially has two fixed modes, or vesafb its obviously a bit different (ditto a lot of embedded devices) You also want one mode embedded in every driver so that if the user space fails, aliens eat your network connection, it panics while mode switch computing or the like you can get a mode to see what went bang. Thats probably single console 640x480 vga timings for the general case and also does for boot up until userspace on disk (or initrd) has the video initialized the way the user wants it in the end. We also mooted caching settings when it made sense (eg when the computation is hard and the mmio whacking trivial) to get better mode change performance on vt flip. Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] - likely compatibility w rv360?
- Original Message -
From: Alan Cox [EMAIL PROTECTED]
Date: Tue, 21 Sep 2004 21:40:54 +0100
To: Dag Bakke [EMAIL PROTECTED]
Subject: Re: [r300] - likely compatibility w rv360?
On Maw, 2004-09-21 at 19:18, Dag Bakke wrote:
1. Is the rv360 (9600xt) close enough to the developers hardware
to
a) benefit from the 2d improvements already made w.r.t. CP
acceleration
b) be of any use for testing purposes
The 6.8.0 server supports 2D acceleration up to the PCI Express cards
like the V5100. I don't personally know which PCI Express are tested
beyond the M300.
-
[pardon the trashed message-id and the broken mailer I am using. Soon, I promise,
I will start using a real mail client.]
Yes. Knew that. I was referring to r300.sf.net:
Current status
* DRM kernel module updated.
* 2d driver updated - CP acceleration appears to work correctly.
I have tried the two patches for linux-2.6.9-rc2 and xorg-x11-6.8.0. A few
notes:
kernel patch:
Added my pci id to drm_pciids.txt, and got:
[drm] Initialized radeon 1.11.0 20020828 on minor 0: ATI Technologies Inc
RV350 AR [Radeon 9600]
Not sure if I should add the secondary pci id. The README doesn't say.
BTW: 2.6.9-rc2 shows a duplicate pci id in drm_pciids.h :
{0x1002, 0x4242, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
{0x1002, 0x4242, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
# lspci
:01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AR
[Radeon 9600]
:01:00.1 Display controller: ATI Technologies Inc RV350 AR [Radeon 9600]
(Secondary)
# lspci -n
:01:00.0 Class 0300: 1002:4152
:01:00.1 Class 0380: 1002:4172
But my card is an XT (rv360). I bought it as an XT. The print on the chip
says XT. And X agrees.
Xorg patch:
I added the patch on top of gentoo's 6.8.0-rc1. Gentoo do use a few patches
on top of vanilla Xorg...
(II) Primary Device is: PCI 01:00:0
(--) Assigning device section with no busID to primary device
(WW) RADEON: No matching Device section for instance (BusID PCI:1:0:1) found
(--) Chipset ATI Radeon 9600XT AR (AGP) found
If I load dri in my xorg.conf, the graphics gets wedged as soon
as I start X. I get more or less garbled stuff from the previous session. I
can move the cursor, but that's it. I can not exit from X with
ctrl-alt-backspace, or shift to the console with ctrl-alt-f1. I also tried
without radeonfb, just in case. I see no evidence of problems in the Xorg
log with dri, which I can review after rebooting via sysrq. Of course, if
the machine panicked, nothing got to the kernel log. And no, my wireless
keyboard does not have keyboard leds..
I am currently without a secondary machine, so i am unable to (try to) log
in via the network to check the kernel log. Will do later this week.
I have attached a diff between Xlog with and without dri, in case it is of
any use to anyone.
dagb-home ~ # diff -u /var/log/Xorg.0.log /root/xlog.dri
--- /var/log/Xorg.0.log 2004-09-22 07:06:38.778552072 +0200
+++ /root/xlog.dri 2004-09-22 07:06:14.861188064 +0200
@@ -11,7 +11,7 @@
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: /var/log/Xorg.0.log, Time: Wed Sep 22 07:06:36
2004
+(==) Log file: /var/log/Xorg.0.log, Time: Wed Sep 22 07:04:13
2004
(==) Using config file: /etc/X11/xorg.conf
(==) ServerLayout configured by hand
(**) |--Screen Screen 1 (0)
@@ -50,7 +50,7 @@
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
-(II) PCI: stages = 0x03, oldVal1 = 0x80008d48, mode1Res1 = 0x8000
+(II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1106,0269 card 1043,8122 rev 80 class 06,00,00 hdr
80
(II) PCI: 00:00:1: chip 1106,1269 card 1043,8122 rev 00 class 06,00,00 hdr
00
@@ -338,6 +338,18 @@
(II) Module v4l: vendor=X.Org Foundation
compiled for 6.8.0, module version = 0.0.1
ABI class: X.Org Video Driver, version 0.7
+(II) LoadModule: dri
+(II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
+(II) Module dri: vendor=X.Org Foundation
+ compiled for 6.8.0, module version = 1.0.0
+ ABI class: X.Org Server Extension, version 0.2
+(II) Loading sub module drm
+(II) LoadModule: drm
+(II) Loading /usr/X11R6/lib/modules/linux/libdrm.a
+(II) Module drm: vendor=X.Org Foundation
+ compiled for 6.8.0, module version = 1.0.0
+ ABI class: X.Org Server Extension, version 0.2
+(II) Loading extension XFree86-DRI
(II) LoadModule: radeon
(II) Loading /usr/X11R6/lib/modules/drivers/radeon_drv.o
(II) Module radeon: vendor=X.Org Foundation
@@ -784,9 +796,44 @@
(==) RADEON(0): Write-combining range (0xa000,0x800)
(II) RADEON(0): Dynamic Clock Scaling Disabled
(WW) RADEON(0): Direct rendering support is
Re: Improve state emitting for ipers
On Tue, 2004-09-21 at 10:41, Dieter Nützel wrote: Am Montag, 20. September 2004 23:14 schrieb Eric Anholt: On Mon, 2004-09-20 at 12:58, Dieter Nützel wrote: Am Montag, 20. September 2004 21:52 schrieb Dieter Nützel: Am Sonntag, 19. September 2004 11:21 schrieb Eric Anholt: The attached patch removes the mandatory emits of all state which were happening after each cmdbuf flush. Instead, we set a flag after a cmdbuf flush saying save the state at the next unlock, which means memcpying the state atoms off. When we actually see the context get lost, then we back up and restore state -- make a new cmdbuf, dirty all state, emit it, flush it, then put the old cmdbuf back. I also removed the dirty/clean state lists and made a single one. The reasoning was that we have to walk the entire list on emit (and twice when the all-dirty is set) anyway, and I felt that this was cleaner. It also fixed some bad cmdbufs that were happening for me (drmCommandWrite: -22) with the CVS code. This gets about a 5% speedup for me in ipers (which I wish was more accurate in its reporting), Do you think it's only 5% for you? It is GREAT. Ipers is back when not faster ever on my system ;-) 31 fps, 825.000 from ~25, ~660.000 = 24% But got progs/demos IperS V1.0 Written by David Bucciarelli ([EMAIL PROTECTED]) Mesa: software DXTn compression/decompression available drmCommandWrite: -22 drmRadeonCmdBuffer: -22 (exiting) [1]Exitcode 234 ./ipers when I cycle through the drawing modes (t/b/n) during wire frame (p). -Dieter And this is a new effect? Don't know. I don't remember that it happened any time before. Couldn't reproduce this using mesademos ipers from debian, and linux-dri-x86 Mesa r200 driver with an 8500, pounding on t/b/n while in wireframe mode. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
