[Dri-devel] Respond for Your FREE Euro
On January 1st 2002, the European countries began using the new Euro. Never before have so many countries with such powerful economies united to use a single currency. Get your piece of history now! We would like to send you a FREE Euro and a FREE report on world currency. Just visit our site to request your Euro: Click Here! In addition to our currency report, you can receive: FREE trading software for commodities and currencies FREE online trading advice via email FREE trading system for stock and commodity traders Find out how the new Euro will affect you. If you are over age 18 and have some risk capital, it's important that you find out how the Euro will change the economic world. Click Here! To be removed from our mailing lists, please click here. All commodity and stock investing is inherently risky. Please carefully evaluate your financial position before trading. Only risk capital should be used. 2060cUFv2-006hJAl3550cDWr5-522ubKx9131JvNS9-750SJxkBiqI6-353bREG70l66 --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC any progress?
On Thu, 7 Nov 2002 01:40:15 +0100 Dieter Nützel <[EMAIL PROTECTED]> wrote: > > No progress. I've pinged S3 every two weeks or so, but haven't > > received a reply since over a month ago. > > Sad, very sad... > > ...it seems to me that we do NOT get much ear at VIA/S3. > > I'll do not buy any products from them before they response, luckily I > have a "clean" AMD system but a Radeon... about time to 'do it ourselves' ? If anyone can do this before christmas, I can put it on my server here in the UK, where it is (until about christmas) still legal to reverse engineer for the purposes of fair use (ie. using the hardware you purchased). --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] libGL{U,w}
These no longer get built by default. Any objections against the attached patch? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast Index: config/cf/host.def === RCS file: /cvsroot/dri/xc/xc/config/cf/host.def,v retrieving revision 1.43 diff -p -u -r1.43 host.def --- config/cf/host.def 30 Oct 2002 10:08:49 - 1.43 +++ config/cf/host.def 7 Nov 2002 14:11:00 - @@ -74,6 +76,8 @@ * Don't change anything below or the build will fail. */ #define BuildServersOnly YES +#define BuildGLULibrary YES +#define BuildGLwLibrary YES #define BuildXvLibrary YES #define BuildXvMCLibrary YES #define BuildLibrariesForXServers NO Index: lib/Imakefile === RCS file: /cvsroot/dri/xc/xc/lib/Imakefile,v retrieving revision 1.11 diff -p -u -r1.11 Imakefile --- lib/Imakefile 27 Oct 2002 06:25:17 - 1.11 +++ lib/Imakefile 7 Nov 2002 14:12:40 - @@ -81,11 +81,11 @@ XRESLIBDIR = XRes GLXLIBDIR = GL #endif -#if BuildGLwLibrary && BuildLibraries +#if BuildGLwLibrary GLWLIBDIR = GLw #endif -#if BuildGLULibrary && BuildLibraries +#if BuildGLULibrary GLULIBDIR = GLU #endif
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 03:13:30PM +0100, Michel Dänzer wrote: > These no longer get built by default. Any objections against the > attached patch? Is there any reason to ? Have we patched/changed these at all from the standard 4.2.0 base ? Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Don, 2002-11-07 at 16:01, Alan Hourihane wrote: > On Thu, Nov 07, 2002 at 03:13:30PM +0100, Michel Dänzer wrote: > > These no longer get built by default. Any objections against the > > attached patch? > > Is there any reason to ? Have we patched/changed these at all from > the standard 4.2.0 base ? I don't know, probably not. My personal reason is that I need them for my Debian packages. Of course, I can patch the tree for building them, but at least the Imakefile part makes no sense to me as it is. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
Alan Hourihane wrote: On Thu, Nov 07, 2002 at 03:13:30PM +0100, Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Is there any reason to ? Have we patched/changed these at all from the standard 4.2.0 base ? When I bring Mesa 5.0 into CVS I'll bring in some GLU changes (mostly compilation warning fixes). Otherwise, I don't think anything has changed in GLU or GLw for a long time. I don't have an opinion on Michel's patch. -Brian --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 04:09:44PM +0100, Michel Dänzer wrote: > On Don, 2002-11-07 at 16:01, Alan Hourihane wrote: > > On Thu, Nov 07, 2002 at 03:13:30PM +0100, Michel Dänzer wrote: > > > These no longer get built by default. Any objections against the > > > attached patch? > > > > Is there any reason to ? Have we patched/changed these at all from > > the standard 4.2.0 base ? > > I don't know, probably not. My personal reason is that I need them for > my Debian packages. Of course, I can patch the tree for building them, > but at least the Imakefile part makes no sense to me as it is. I don't have a problem with turning them on. Check with Eric Anholt to make sure there isn't a FreeBSD build problem with that patch. Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 08:17:06AM -0700, Brian Paul wrote: > Alan Hourihane wrote: > >On Thu, Nov 07, 2002 at 03:13:30PM +0100, Michel Dänzer wrote: > > > >>These no longer get built by default. Any objections against the > >>attached patch? > > > > > >Is there any reason to ? Have we patched/changed these at all from > >the standard 4.2.0 base ? > > When I bring Mesa 5.0 into CVS I'll bring in some GLU changes (mostly > compilation warning fixes). Have you sent the changes back to the ogl-sample list at SGI ? If so, we'll pick them changes up when XFree86 merges the ogl-sample directory again. Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
Alan Hourihane wrote: On Thu, Nov 07, 2002 at 08:17:06AM -0700, Brian Paul wrote: Alan Hourihane wrote: On Thu, Nov 07, 2002 at 03:13:30PM +0100, Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Is there any reason to ? Have we patched/changed these at all from the standard 4.2.0 base ? When I bring Mesa 5.0 into CVS I'll bring in some GLU changes (mostly compilation warning fixes). Have you sent the changes back to the ogl-sample list at SGI ? I haven't. I will but there's no guarantee that SGI will apply my patch in a timely manner. If so, we'll pick them changes up when XFree86 merges the ogl-sample directory again. -Brian --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Glaxium...
Hello all, I tried the Lan-test (build 0197) of parsec. I noticed the odd texture problems both with TCL enabled and disabled on my 8500, so it doesn't look like TCL is the culprit. Adam On Wed, 6 Nov 2002, Adam K Kirchhoff wrote: > > On Wed, 6 Nov 2002, Dieter [iso-8859-1] Nützel wrote: > > > Am Mittwoch, 6. November 2002 23:23 schrieb Adam K Kirchhoff: > > > Hello all, > > > > > > These two links show screenshots of glaxium on two separate > > > machines, one with an r100 (original 64 Meg Radeon) and one with an r200 > > > (Radeon 8500). > > > > > > http://memory.visualtech.com/glaxium-r100.png > > > http://memory.visualtech.com/glaxium-r200.png > > > > > > You may notice that, quite frankly, the floor looks much nicer on > > > the r100 than on the r200. Can anyone explain why this would be the case? > > > Shouldn't the r200 support all the same extensions as the r100? > > > > Broken textures in the r200 branch? > > Have you tried with TCL disabled? > > I just did :-) > > > Please try both with parsec. I see some texture corruption with the r200 > > there, too. > > I'll try it with parsec when I get the chance (*hopefully* tonight), but > disable TCL with R200_NO_TCL=true didn't help. Still looks the same. > > Adam > > > > > --- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Glaxium...
On Wed, Nov 06, 2002 at 11:41:00PM +0100, Dieter Nützel wrote: > Am Mittwoch, 6. November 2002 23:23 schrieb Adam K Kirchhoff: > > Hello all, > > > > These two links show screenshots of glaxium on two separate > > machines, one with an r100 (original 64 Meg Radeon) and one with an r200 > > (Radeon 8500). > > > > http://memory.visualtech.com/glaxium-r100.png > > http://memory.visualtech.com/glaxium-r200.png > > > > You may notice that, quite frankly, the floor looks much nicer on > > the r100 than on the r200. Can anyone explain why this would be the case? > > Shouldn't the r200 support all the same extensions as the r100? > > Broken textures in the r200 branch? > Have you tried with TCL disabled? > > Please try both with parsec. I see some texture corruption with the r200 > there, too. I know that glaxium is, but is parsec using DOT3? If so, I believe that may be the problem. I know that the R200 driver doesn't handle the scale factor correctly for ARB_texture_env_dot3 (it always uses a 1x scale). However, I don't think /that/ by itself would cause that problem. If that were the case, then it would run unbearably slow on R100 (using a non-1x scale causes a sw fallback on R100). Do we have any DOT3 tests? I didn't see any in glean. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Actually if they're not built, I think we should ditch them from cvs. We're not working on them. Keith --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Glaxium...
On Thu, 7 Nov 2002, Ian Romanick wrote: > On Wed, Nov 06, 2002 at 11:41:00PM +0100, Dieter Nützel wrote: > > Am Mittwoch, 6. November 2002 23:23 schrieb Adam K Kirchhoff: > > > Hello all, > > > > > > These two links show screenshots of glaxium on two separate > > > machines, one with an r100 (original 64 Meg Radeon) and one with an r200 > > > (Radeon 8500). > > > > > > http://memory.visualtech.com/glaxium-r100.png > > > http://memory.visualtech.com/glaxium-r200.png > > > > > > You may notice that, quite frankly, the floor looks much nicer on > > > the r100 than on the r200. Can anyone explain why this would be the case? > > > Shouldn't the r200 support all the same extensions as the r100? > > > > Broken textures in the r200 branch? > > Have you tried with TCL disabled? > > > > Please try both with parsec. I see some texture corruption with the r200 > > there, too. > > I know that glaxium is, but is parsec using DOT3? If so, I believe that may > be the problem. I know that the R200 driver doesn't handle the scale factor > correctly for ARB_texture_env_dot3 (it always uses a 1x scale). However, I > don't think /that/ by itself would cause that problem. If that were the > case, then it would run unbearably slow on R100 (using a non-1x scale causes > a sw fallback on R100). > > Do we have any DOT3 tests? I didn't see any in glean. I should point out that I've never seen parsec on an r100 card, so I don't know if the texture problems I saw were limited to the r200. Adam --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 08:37:57AM -0700, Brian Paul wrote: > Alan Hourihane wrote: > >On Thu, Nov 07, 2002 at 08:17:06AM -0700, Brian Paul wrote: > > > >>Alan Hourihane wrote: > >> > >>>On Thu, Nov 07, 2002 at 03:13:30PM +0100, Michel Dänzer wrote: > >>> > >>> > These no longer get built by default. Any objections against the > attached patch? > >>> > >>> > >>>Is there any reason to ? Have we patched/changed these at all from > >>>the standard 4.2.0 base ? > >> > >>When I bring Mesa 5.0 into CVS I'll bring in some GLU changes (mostly > >>compilation warning fixes). > > > > > >Have you sent the changes back to the ogl-sample list at SGI ? > > I haven't. I will but there's no guarantee that SGI will apply my > patch in a timely manner. O.k. If you want to commit them independently of the Mesa 5.0 merge, then we should be able to get them into XFree86 4.3.0 Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 03:56:46PM +, Keith Whitwell wrote: > Michel Dänzer wrote: > >These no longer get built by default. Any objections against the > >attached patch? > > Actually if they're not built, I think we should ditch them from cvs. > We're not working on them. Now that sound like a better deal. Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Differences between R100 & R200 for GL_PREVIOUS?
I've been going through the R100 driver in the texmem branch. I'm trying to make it more like the R200 driver. This should make it easier for me to make the texmem changes to the R200 driver and back-port features (npot textures & YCBCR textures) to the R100 driver. I've come across two differences in UpdateTextureEnv for which I could use some clarification. 1. The two drivers handle GL_PREVIOUS in GL_COMBINE mode quite differently. The R200 driver does pretty much what I would expect. If we setting-up texture unit 0, use the primary color as the input. Otherwise, texture unit n-1 is used. The R100 driver does some funky thing with the RADEON_COLOR_ARG_A_CURRENT_* values. Is that even correct? 2. The R200 driver does some special casing when _ReallyEnabled == 0. Why is that needed, and should it be copied in the R100 driver? That's all for now, but I'm sure I'll have more questions later... -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI w/o GL
Hello all: I'm working on incorporating a Geode accelerated driver into a LC build. During the process, I've weaseled our X11 (4.2.1) build down a fair bit - in part by removing GL support. My final defect is that a multithreaded application displaying 4 distinct changing images in a quad screen seems to be incurring race conditions in the graphics pipeline. Somehow I need to implement locking in the Geode DDX driver. When I started looking around, it seems that DRI/DRM is the established way to do this - here are my questions or concerns: - We don't need GL support, and I would rather keep it out of our X server for space reasons. Is it possible to use DRI/DRM locking without GL support compiled in? I did not see an X build flag in config/cf for this feature. - The documentation states that each hardware component supported requires a kernel module, gl/mesa module, and an XAA module. I have none of these (the DDX driver doesn't even have a geode_dri.c file). Is it feasible to implement a simple (locking only) kernel module, a lobotomized GL module, and incorporate a geode_dri.c in a short period of time? If the architecture would support this, how many LOC would you estimate? I realize that if my first question is negative, this point is moot. My alternative to implementing limited DRI support is to simply hardcode the locking into the Geode DDX driver (thank goodness for open source). My first thought was to have a kernel module lock held during accelerated routines; the design of the DDX seems to lend itself to this; each OP has a SetupOP() and a DoOP() routine. The km lock would be held accross these two calls, other requests would stall in a wait queue. Reading through the documentation and reviewing some debugging results makes me second guess this solution. Would this type of locking stall the Xserver when it went into the wait queue? I'm still diggin' round in the source & documentation; but I felt I had enough info to post these questions. TIA & please cross followup to [EMAIL PROTECTED] -- Keith Hellman Software Engineer [EMAIL PROTECTED] Voice: 303.477.7757 --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: > Michel Dänzer wrote: > > These no longer get built by default. Any objections against the > > attached patch? > > Actually if they're not built, I think we should ditch them from cvs. We're > not working on them. In that case I'd vote again for removing unused drivers etc. as well. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
Michel Dänzer wrote: On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: Michel Dänzer wrote: These no longer get built by default. Any objections against the attached patch? Actually if they're not built, I think we should ditch them from cvs. We're not working on them. In that case I'd vote again for removing unused drivers etc. as well. I'm ok with that too, as long as it simplifies rather than complicates the lives of people who are doing XFree merges. Keith --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI w/o GL
I think your really confused on how things fit together. I'd be really hard pushed to see how a multithreaded application is causing the 2D driver to fail. It's more likely that the 2D driver has problems anyway and the multithreaded app is triggering this. The DRI won't help you at all for this. Alan. On Thu, Nov 07, 2002 at 04:15:15PM +, khellman wrote: > Hello all: > > I'm working on incorporating a Geode accelerated driver into a LC > build. During the process, I've weaseled our X11 (4.2.1) build down a > fair bit - in part by removing GL support. > > My final defect is that a multithreaded application displaying 4 > distinct changing images in a quad screen seems to be incurring race > conditions in the graphics pipeline. Somehow I need to implement > locking in the Geode DDX driver. When I started looking around, it > seems that DRI/DRM is the established way to do this - here are my > questions or concerns: > > - We don't need GL support, and I would rather keep it out of our X > server for space reasons. Is it possible to use DRI/DRM locking > without GL support compiled in? I did not see an X build flag in > config/cf for this feature. > - The documentation states that each hardware component supported > requires a kernel module, gl/mesa module, and an XAA module. I have > none of these (the DDX driver doesn't even have a geode_dri.c file). > Is it feasible to implement a simple (locking only) kernel module, a > lobotomized GL module, and incorporate a geode_dri.c in a short period > of time? If the architecture would support this, how many LOC would > you estimate? I realize that if my first question is negative, this > point is moot. > > My alternative to implementing limited DRI support is to simply hardcode > the locking into the Geode DDX driver (thank goodness for open source). > My first thought was to have a kernel module lock held during > accelerated routines; the design of the DDX seems to lend itself to > this; each OP has a SetupOP() and a DoOP() routine. The km lock would > be held accross these two calls, other requests would stall in a wait > queue. > > Reading through the documentation and reviewing some debugging results > makes me second guess this solution. Would this type of locking stall > the Xserver when it went into the wait queue? > > I'm still diggin' round in the source & documentation; but I felt I had > enough info to post these questions. > > TIA & please cross followup to [EMAIL PROTECTED] > > -- > Keith Hellman > Software Engineer > [EMAIL PROTECTED] > Voice: 303.477.7757 > > > --- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 04:32:03PM +, Keith Whitwell wrote: > Michel Dänzer wrote: > >On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: > > > >>Michel Dänzer wrote: > >> > >>>These no longer get built by default. Any objections against the > >>>attached patch? > >>> > >>Actually if they're not built, I think we should ditch them from cvs. > >>We're not working on them. > >> > > > >In that case I'd vote again for removing unused drivers etc. as well. > > I'm ok with that too, as long as it simplifies rather than complicates the > lives of people who are doing XFree merges. I wouldn't like to remove the drivers. They don't cause any import conflicts and they're useful to those who want to start a DRI driver for another chipset. But GLU is a pain in the neck. It has alsorts of $Id, $Revision and $Date cvs tags that get updated during commits. This causes import conflicts and the work involved to resolve them. I doubt we'll ever work on GLU or GLw. Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Don, 2002-11-07 at 17:38, Alan Hourihane wrote: > On Thu, Nov 07, 2002 at 04:32:03PM +, Keith Whitwell wrote: > > Michel Dänzer wrote: > > >On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: > > > > > >>Michel Dänzer wrote: > > >> > > >>>These no longer get built by default. Any objections against the > > >>>attached patch? > > >>> > > >>Actually if they're not built, I think we should ditch them from cvs. > > >>We're not working on them. > > >> > > > > > >In that case I'd vote again for removing unused drivers etc. as well. > > > > I'm ok with that too, as long as it simplifies rather than complicates the > > lives of people who are doing XFree merges. > > I wouldn't like to remove the drivers. They don't cause any import conflicts > and they're useful to those who want to start a DRI driver for another chipset. They can trivially be added back in that case, and these libraries for people who want to provide packages off the DRI tree. > But GLU is a pain in the neck. It has alsorts of $Id, $Revision and $Date > cvs tags that get updated during commits. This causes import conflicts > and the work involved to resolve them. I doubt we'll ever work on GLU or GLw. I see, I'll cope. Anyway, back to the point of my patch: even in the context of the XFree86 tree, does it make sense only to build these libraries when all libraries are built, even if the user explicitly wants to build them? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 05:48:22PM +0100, Michel Dänzer wrote: > On Don, 2002-11-07 at 17:38, Alan Hourihane wrote: > > On Thu, Nov 07, 2002 at 04:32:03PM +, Keith Whitwell wrote: > > > Michel Dänzer wrote: > > > >On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: > > > > > > > >>Michel Dänzer wrote: > > > >> > > > >>>These no longer get built by default. Any objections against the > > > >>>attached patch? > > > >>> > > > >>Actually if they're not built, I think we should ditch them from cvs. > > > >>We're not working on them. > > > >> > > > > > > > >In that case I'd vote again for removing unused drivers etc. as well. > > > > > > I'm ok with that too, as long as it simplifies rather than complicates the > > > lives of people who are doing XFree merges. > > > > I wouldn't like to remove the drivers. They don't cause any import conflicts > > and they're useful to those who want to start a DRI driver for another chipset. > > They can trivially be added back in that case, and these libraries for > people who want to provide packages off the DRI tree. Why remove them, if we end up having to put them back ? And for the libraries - they haven't changed since 4.2.0 - so why would people want to put them in packages ? > > But GLU is a pain in the neck. It has alsorts of $Id, $Revision and $Date > > cvs tags that get updated during commits. This causes import conflicts > > and the work involved to resolve them. I doubt we'll ever work on GLU or GLw. > > I see, I'll cope. O.k. > Anyway, back to the point of my patch: even in the context of the > XFree86 tree, does it make sense only to build these libraries when all > libraries are built, even if the user explicitly wants to build them? Like I said, Check with Eric. I know he added a BuildLibraries to the XThrStub one, so maybe there's an underlying build problem somewhere else that needs to be fixed before we can apply this. Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Glaxium...
On Thu, Nov 07, 2002 at 07:48:55AM -0800, Ian Romanick wrote:
> On Wed, Nov 06, 2002 at 11:41:00PM +0100, Dieter Nützel wrote:
> > Am Mittwoch, 6. November 2002 23:23 schrieb Adam K Kirchhoff:
> > > Hello all,
> > >
> > > These two links show screenshots of glaxium on two separate
> > > machines, one with an r100 (original 64 Meg Radeon) and one with an r200
> > > (Radeon 8500).
> > >
> > > http://memory.visualtech.com/glaxium-r100.png
> > > http://memory.visualtech.com/glaxium-r200.png
> > >
> > > You may notice that, quite frankly, the floor looks much nicer on
> > > the r100 than on the r200. Can anyone explain why this would be the case?
> > > Shouldn't the r200 support all the same extensions as the r100?
> >
> > Broken textures in the r200 branch?
> > Have you tried with TCL disabled?
> >
> > Please try both with parsec. I see some texture corruption with the r200
> > there, too.
>
> I know that glaxium is, but is parsec using DOT3? If so, I believe that may
> be the problem. I know that the R200 driver doesn't handle the scale factor
> correctly for ARB_texture_env_dot3 (it always uses a 1x scale). However, I
> don't think /that/ by itself would cause that problem. If that were the
> case, then it would run unbearably slow on R100 (using a non-1x scale causes
> a sw fallback on R100).
Actually, I found the bug. The R200 driver exports EXT_texture_env_dot3,
but the GL_COMBINE case in r200UpdateTextureEnv (r200_texstate.c) doesn't
have cases for the GL_DOT3_{RGB,RGBA}_EXT enums. The _EXT version *IS*
different (and has different enums) than the ARB/OpenGL 1.3 version.
Adding case-statements for the _EXT enums everywhere there's a non-EXT enum
should fix the problem, modulo the incorrect implmentation of the non-EXT
version mentioned above. There was some discussion of this a couple months
ago WRT the R100 driver.
--
Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html
---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 05:04:41PM +, Alan Hourihane wrote: > On Thu, Nov 07, 2002 at 05:48:22PM +0100, Michel Dänzer wrote: > > On Don, 2002-11-07 at 17:38, Alan Hourihane wrote: > > > On Thu, Nov 07, 2002 at 04:32:03PM +, Keith Whitwell wrote: > > > > Michel Dänzer wrote: > > > > >On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: > > > > > > > > > >>Michel Dänzer wrote: > > > > >> > > > > >>>These no longer get built by default. Any objections against the > > > > >>>attached patch? > > > > >>> > > > > >>Actually if they're not built, I think we should ditch them from cvs. > > > > >>We're not working on them. > > > > >> > > > > > > > > > >In that case I'd vote again for removing unused drivers etc. as well. > > > > > > > > I'm ok with that too, as long as it simplifies rather than complicates the > > > > lives of people who are doing XFree merges. > > > > > > I wouldn't like to remove the drivers. They don't cause any import conflicts > > > and they're useful to those who want to start a DRI driver for another chipset. > > > > They can trivially be added back in that case, and these libraries for > > people who want to provide packages off the DRI tree. > > Why remove them, if we end up having to put them back ? And for the libraries - > they haven't changed since 4.2.0 - so why would people want to put them > in packages ? For most of the cards, that's a BIG if. Quite a few of the cards that we're packing around drivers for don't even have any 3D acceleration to support. The sun*, tseng, tga, i128, cyrix, cirrus, chips, and ark drivers come to mind. The only drivers for which we don't already have 3D support for (in the trunk) that we should probably keep around are the i740 (just in case!), nv, s3virge, and savage. If somebody could scare up docs, rendition might could be added to the list... -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Don, 2002-11-07 at 18:04, Alan Hourihane wrote: > On Thu, Nov 07, 2002 at 05:48:22PM +0100, Michel Dänzer wrote: > > On Don, 2002-11-07 at 17:38, Alan Hourihane wrote: > > > On Thu, Nov 07, 2002 at 04:32:03PM +, Keith Whitwell wrote: > > > > Michel Dänzer wrote: > > > > >On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: > > > > > > > > > >>Michel Dänzer wrote: > > > > >> > > > > >>>These no longer get built by default. Any objections against the > > > > >>>attached patch? > > > > >>> > > > > >>Actually if they're not built, I think we should ditch them from cvs. > > > > >>We're not working on them. > > > > >> > > > > > > > > > >In that case I'd vote again for removing unused drivers etc. as well. > > > > > > > > I'm ok with that too, as long as it simplifies rather than complicates the > > > > lives of people who are doing XFree merges. > > > > > > I wouldn't like to remove the drivers. They don't cause any import conflicts > > > and they're useful to those who want to start a DRI driver for another chipset. > > > > They can trivially be added back in that case, and these libraries ...are useful... > > for people who want to provide packages off the DRI tree. > > Why remove them, if we end up having to put them back ? And for the libraries - > they haven't changed since 4.2.0 - so why would people want to put them > in packages ? Because they're in the same package as libGL, it would make life a bit easier, but like I said I'll cope. > > Anyway, back to the point of my patch: even in the context of the > > XFree86 tree, does it make sense only to build these libraries when all > > libraries are built, even if the user explicitly wants to build them? > > Like I said, Check with Eric. I know he added a BuildLibraries to > the XThrStub one, so maybe there's an underlying build problem somewhere > else that needs to be fixed before we can apply this. IMHO that should be handled somewhere in config/ then instead of the Imakefile preventing this where it works. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 09:16:49AM -0800, Ian Romanick wrote: > On Thu, Nov 07, 2002 at 05:04:41PM +, Alan Hourihane wrote: > > On Thu, Nov 07, 2002 at 05:48:22PM +0100, Michel Dänzer wrote: > > > On Don, 2002-11-07 at 17:38, Alan Hourihane wrote: > > > > On Thu, Nov 07, 2002 at 04:32:03PM +, Keith Whitwell wrote: > > > > > Michel Dänzer wrote: > > > > > >On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: > > > > > > > > > > > >>Michel Dänzer wrote: > > > > > >> > > > > > >>>These no longer get built by default. Any objections against the > > > > > >>>attached patch? > > > > > >>> > > > > > >>Actually if they're not built, I think we should ditch them from cvs. > > > > > >>We're not working on them. > > > > > >> > > > > > > > > > > > >In that case I'd vote again for removing unused drivers etc. as well. > > > > > > > > > > I'm ok with that too, as long as it simplifies rather than complicates the > > > > > lives of people who are doing XFree merges. > > > > > > > > I wouldn't like to remove the drivers. They don't cause any import conflicts > > > > and they're useful to those who want to start a DRI driver for another chipset. > > > > > > They can trivially be added back in that case, and these libraries for > > > people who want to provide packages off the DRI tree. > > > > Why remove them, if we end up having to put them back ? And for the libraries - > > they haven't changed since 4.2.0 - so why would people want to put them > > in packages ? > > For most of the cards, that's a BIG if. Quite a few of the cards that we're > packing around drivers for don't even have any 3D acceleration to support. > The sun*, tseng, tga, i128, cyrix, cirrus, chips, and ark drivers come to > mind. The only drivers for which we don't already have 3D support for (in > the trunk) that we should probably keep around are the i740 (just in case!), > nv, s3virge, and savage. If somebody could scare up docs, rendition might > could be added to the list... Your forgetting that sun* has the ffb driver. If your volunteering to do the merges in future Ian - go ahead and remove them. :) Alan. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, Nov 07, 2002 at 05:26:40PM +0100, Michel Dänzer wrote: > On Don, 2002-11-07 at 16:56, Keith Whitwell wrote: > > Michel Dänzer wrote: > > > These no longer get built by default. Any objections against the > > > attached patch? > > > > Actually if they're not built, I think we should ditch them from cvs. We're > > not working on them. > > In that case I'd vote again for removing unused drivers etc. as well. Err, no please, i still have plans to work on the gamma driver, but have not that much time right now (I guess it would be the prime candidate for removal, isn't it ?) Friendly, Sven Luther --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] libGL{U,w}
On Thu, 2002-11-07 at 09:04, Alan Hourihane wrote: > On Thu, Nov 07, 2002 at 05:48:22PM +0100, Michel Dänzer wrote: > > Anyway, back to the point of my patch: even in the context of the > > XFree86 tree, does it make sense only to build these libraries when all > > libraries are built, even if the user explicitly wants to build them? > > Like I said, Check with Eric. I know he added a BuildLibraries to > the XThrStub one, so maybe there's an underlying build problem somewhere > else that needs to be fixed before we can apply this. That was because libXThrStub is not in the DRI tree, and BuildLibraries was is to NO for the DRI tree (I was just reverting a change made during the 4.2.99.2 merge). libXThrStub is only used by libX11, which is also not in the tree. Although I haven't actually tried a build with libGLU/libGLw, I don't expect there to be any problems. -- Eric Anholt <[EMAIL PROTECTED]> http://people.freebsd.org/~anholt/dri/ --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mesa 4.1 branch
I just wanted to say that the mesa 4.1 branch is looking quite nice. The visuals for Wolfenstein and others looks very nice on the r200. One thing that sems to effect most games that I've tried is that when you change resolution or hit alt enter it seems to turn everything this green color and I have to quit the app and start it back up to get things looking right. Even doing a /vid_restart in any quake3 based game will do it. --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
