[Dri-devel] Re: SPAM : DRI Devel ratio
> >> Is this a good idia filter out all messages with html??? > >> > > > >only if you think people who send html email have nothing usefull to > >say. I'll ask a related question, is it good to filter out messages with > >foriegn charsets, like, say, koi8-r? > > No, it is actually a bad idea. A very bad idea. A while back, I > blocked Japanese encodings because a large portion of spam I > received was in Japanese encoding (sp?). I was being sarcastic, his message was encoded with koi8-r, which, along with being html, is one of the indescriminate reasons people block email (and get a good number of false positives) -- Russ Dill <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration File Format Example
> > > > > ... > > > > > > I'm coming to conclusion more the more I think about it. I really can't > come up with a good, real-world case to argue for > application-then-device. Most of the cases where you'd want the > application at the top level could be handled by putting a ' id="*">' around it. I would think that the common case would be: most general settings device 0 settings device 1 settings application x settings settings specific to device 0 on application x etc I don't think "settings specific to device 0 on application x" would ever actually come up, but the structure suggested would allow it. -- Russ Dill <[EMAIL PROTECTED]> --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC
> As for talking to S3, the contact I had was apparently a dead end. With all > the mergers/spin-offs/acquisitions that S3 has gone through in recent years > (Sonic Blue, Via, Diamond, ATI) it's not clear who might even own the patents > anymore. > I find it somehow ironic that the best way to find out who owns/enforces the patent is to ignore them, and violate the patent. -- Russ Dill <[EMAIL PROTECTED]> --- This SF.NET email is sponsored by: The Best Geek Holiday Gifts! Time is running out! Thinkgeek.com has the coolest gifts for your favorite geek. Let your fingers do the typing. Visit Now. T H I N K G E E K . C O Mhttp://www.thinkgeek.com/sf/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New ATI FireGL drivers announced
> Let me express that i do _not_ object to any of the DRI-Devel works. > DRI did great job and it resolves for situations where ATI > cant provide solutions as of today and possibly long term. > Just saying embedded Radeon chipsets, ATI chipsets on BSD, > old ATI chipsets prior to the R200 and further any sort of > experimental and custom extensions to the DRI open source > drivers. > > Let's hope, no one does mind this mailing. I appreciate the hard work put into a commercial driver, and I'm sure a very large number of users will really appreciate the S3TC support, since an open solution has not yet been implemented due to legal issues. By reading the readme, xinerma+dri is not yet supported. Is support planned for this? if so, when? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Glaxium...
On Wed, 2002-11-06 at 15:23, Adam K Kirchhoff wrote: > > 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? ... looks like one in textured and one is not --- 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] Ann: nightly snapshots resumed
On Fri, 2002-11-01 at 08:38, Michel Dänzer wrote: > On Fre, 2002-11-01 at 16:30, Russ Dill wrote: > > On Fri, 2002-11-01 at 08:15, Alan Hourihane wrote: > > > On Fri, Nov 01, 2002 at 08:02:10AM -0700, Russ Dill wrote: > > > > related note: I was setting up a mach64 for one of my friends, and X > > > > dying with a SIGILL. It looks like the snapshots are being compiled with > > > > 686 optimizations (this was a k6) > > > > > > If you've ended up using the XFree86 4.2.99.2 Xserver with the mach64 > > > snapshots you've hit a version issue with libpcidata.a. > > > > > > The functions changed between 4.2.0 and 4.2.99.2 and so a 4.2.99.2 > > > Xserver can no longer load a 4.2.0 libpcidata.a module. You need > > > the 4.2.99.2 version as well. > > > > I'm running 4.2.1 (debian sid), and the signal is most definately signal > > 4, aka SIGILL, aka illegal instruction > > Have you read http://dri.sourceforge.net/snapshots/README.Debian ? have you noticed that these snapshots are a month old? (or 2 weeks in the case of the mach64 branch) it doesn't change my point though, as far as I can tell, the tgz snapshots are being compiled with 686 optimizations --- 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] Ann: nightly snapshots resumed
On Fri, 2002-11-01 at 08:15, Alan Hourihane wrote: > On Fri, Nov 01, 2002 at 08:02:10AM -0700, Russ Dill wrote: > > related note: I was setting up a mach64 for one of my friends, and X > > dying with a SIGILL. It looks like the snapshots are being compiled with > > 686 optimizations (this was a k6) > > If you've ended up using the XFree86 4.2.99.2 Xserver with the mach64 > snapshots you've hit a version issue with libpcidata.a. > > The functions changed between 4.2.0 and 4.2.99.2 and so a 4.2.99.2 > Xserver can no longer load a 4.2.0 libpcidata.a module. You need > the 4.2.99.2 version as well. I'm running 4.2.1 (debian sid), and the signal is most definately signal 4, aka SIGILL, aka illegal instruction --- 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] Ann: nightly snapshots resumed
related note: I was setting up a mach64 for one of my friends, and X dying with a SIGILL. It looks like the snapshots are being compiled with 686 optimizations (this was a k6) --- 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] Mesa 4.1 branch
On Tue, 2002-10-15 at 10:01, Stefan Lange wrote: > Q3A: stable (at least for the time I tested), but not very fast. In fact > it shows the same symptoms I got with earlier versions of DRI-trunk > (before around 2002-10-11): poor overall speed, and a framerate that > maxes out at 50 FPS. Is the r200-code in your branch from before that > date? If yes, that would explain the behaviour. This speed problem is somehow related to displaying the players weapon, or status. If you are playing q3a, and switch to free fly mode, the fps jumps to around 100-250fps --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: trunk)
> > But Q3A get best (~136 fps) only with "setenv R200_NO_USLEEPS 1". > > Stefan Lange reported that Quake3 gives him max 50FPS which sounds like > a usleep limit. I saw that usleep is used in several places in > r200_ioctl.c. I'm afraid that my change in r200Clear may be causing > trouble. > > I could actually reproduce the 50FPS limit on my Radeon7500 by changing > radeonClear to behave like r200Clear (set RADEON_MAX_CLEAR to 1 and put > in a usleep instead of busy waiting). With RADEON_MAX_CLEAR == 2 > everything seems fine. But maybe it wouldn't hurt increasing the limit a > bit further, just to be sure. I've noticed in q3a, that if I'm following someone, it'll often (but not always) stick at 50fps. If I free fly, I see 2, and often 3's in the third fps column (if I look at the floor, I can get 4's, and occasionly 5's) this is with a radeon 8500 and AMD 2000XP+ (no enviromental variables set) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: Ann: gcc-2.96 compiled snapshots available (I'm going tosmack redhat)
> There's absolutely no valid technical reason that glibc in Red > Hat Linux 8.0 should not have been included. It is superior to > glibc 2.2 in numerous ways, including standards compliance, > performance, and also various new features. Every mainstream > distribution will be using glibc 2.3 likely within the next 6 > months, and there's no reason not to. In addition, the other > distributions will benefit greatly from all of the legwork that > has been done by Red Hat, and that includes beta testing, bug > fixing, stabilization, etc. I do appreciate the work that redhat does, and if their users are willing to be their beta testers and "stabilizers" for glibc, then I do suppose its up to them. > > >I really do see your frustration, as now anyone who develops software on > >redhat (at least those that keep up with redhat) cannot release binaries > >and expect them to work on anyone elses system. You don't need to worry > >about compiling for every system out there, just what is current > >release. > > Sure you can. If you need to build binaries which are compatible > with older glibc, simply compile them using older compat glibc. > It's quite simple actually. Again, don't spread FUD. please, explain, as this has been the whole reason this is come up, tell us how, and we'll all be much happier. > >As far as actually getting this done, redhat has provided cross compiler > >rpms in the past, so you may be able to get these, and cross compile for > >glibc2.2. I don't see a rough time for binary snapshots, just a rough > >time for developers using cvs snapshots of glibc > > A cross compiler is something used to produce binaries for an > architecture other than the architecture the compiler is running > on. Not sure what that has to do with glibc. you can compile gcc against any libc (different versions, different libc's), etc. So, if you compile a gcc against uclibc, and install that, its a cross-compiler. same deal with other versions of glibc > I hope this clarifies any misunderstandings, and misconceptions > that people have about glibc 2.2.9x and glibc 2.3 which is now > officially released. If not, please feel free to discuss the > issue on the glibc mailing lists, where I'm sure all of the glibc > developers would be glad to discuss any concerns people may have. as of 7 hours ago, its time to upgrade --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Ann: gcc-2.96 compiled snapshots available
On Wed, 2002-10-02 at 15:56, Alan Cox wrote: > > release version, and using that. CVS versions of software often contain > > new bugs and even security vulnerabilities, it is far more prudent to > > work with a release version of such a major system component. Because of > > this, most distros will probably wait until it becomes a release until > > they include it. > > Ask the glibc 2.3 maintainer. I can tell you for free that 2.3 contains > fixes for security holes in 2.2-*. I can't tell you the holes because > CERT won't let anyone yet. So thats not true. so, you can't backport them, because then people might figure out what the problems actually are, so instead, they just leave the door wide open? kindof a nightmare for a glibc packager (and user), use cvs (or prereleases) or else...I wonder if this sort of thing is done with the kernel too (2.4 vs 2.5). > > As far as actually getting this done, redhat has provided cross compiler > > rpms in the past, so you may be able to get these, and cross compile for > > glibc2.2. I don't see a rough time for binary snapshots, just a rough > > time for developers using cvs snapshots of glibc > > Yawn and its not a CVS snapshot. > > If instead of whining someone figured out why the weirdass XFree86 > binary module load has problems with this we might get somewhere > instead. > russ:~/src/dripkg$ ldd r200/r200_dri.so r200/r200_dri.so: /lib/libc.so.6: version `GLIBC_2.3' not found (required by r200/r200_dri.so) libm.so.6 => /lib/libm.so.6 (0x401a6000) ... from xc/lib/GL/mesa/src/drv/r200/Imakefile LIBNAME = r200_dri.so SharedDriModuleTarget($(LIBNAME),DONE $(OBJS),$(OBJS)) InstallDynamicModule($(LIBNAME),$(MODULEDIR),dri) and SharedDriModuleTarget contains: $(CC) -o $@~ -Wl,--version-script=$@.map $(SHLIBLDFLAGS) solist $(REQUIREDLIBS) BaseShLibReqs @@\ and: #if LinuxCLibMajorVersion <= 5 ... #define BaseShLibReqs #else /* With GNU libc 2 this works fine. */ #define BaseShLibReqs -lc #endif now the question is, why is it linked that way (I don't know the X source very well) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Ann: gcc-2.96 compiled snapshots available (I'm going to smack redhat)
> >*please* find a machine with a copy of glibc2.2, wait until glibc2.3 > >actually becomes a release to compile against it (or, if in the case of > >redhat, distribute it with your distro) > > The final RHL 8.0 was released 2 days ago. I'll upgrade soon but I > already checked and it has the same version of gcc. Please note that > the snapshots are done on workstation in the nigth, and I needed to > upgrade for several reasons regarding my work. I have no other machine > powerfull enough to do all these snapshots. > > What I'll do is install a older version of Gentoo in a chroot'ed > environment to compile the snapshots using gcc-2.95.3 and glibc-2.2.5 for > the _time being_. > > But I see rough times ahead for the binary snapshots. I surely can't make > one for each system out there. And if the others distros don't also > upgrade to glic-2.3 then I think the best is to completely stop the > snapshots builds and replace them with a nice set of scripts which > people can use to make their own customized snapshot. upgrade to glibc-2.3? technically, such a thing doesn't exist yet, so to ask every distro to upgrade to it... redhat is making cvs snapshots of glibc, and distributing those instead of patching important bugs in the release version, and using that. CVS versions of software often contain new bugs and even security vulnerabilities, it is far more prudent to work with a release version of such a major system component. Because of this, most distros will probably wait until it becomes a release until they include it. I really do see your frustration, as now anyone who develops software on redhat (at least those that keep up with redhat) cannot release binaries and expect them to work on anyone elses system. You don't need to worry about compiling for every system out there, just what is current release. As far as actually getting this done, redhat has provided cross compiler rpms in the past, so you may be able to get these, and cross compile for glibc2.2. I don't see a rough time for binary snapshots, just a rough time for developers using cvs snapshots of glibc --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Ann: gcc-2.96 compiled snapshots available (I'm going to smackredhat)
> > > I just uploaded a set of binary snapshots built from the CVS head > > > using RedHat's compat-gcc-7.3-2.96.110 package (which produces > > > code compatible with the gcc bundled with the RedHat 7.3 and is > > > the same which was producing the snapshots before). > > > > Unfortunately this appears to be not very helpful for those of us > > who test-run the snapshots on a regular basis against known OpenGL > > programs. This is from the radeon-20020930 binary snapshot: > > > > libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/radeon_dri.so > > libGL error: dlopen failed: /lib/libc.so.6: version `GLIBC_2.3' not > > found (required by > > /usr/X11R6/lib/modules/dri/radeon_dri.so) > > > > > > _I_ don't have glibc-2.3 on my system and I believe, others don't > > either. So this _might_ render the binary snapshots pretty useless. > But so the 2D driver from that snapshot works for you? Its c code, so I don't think the version of gcc is that important, what matters is the GLIBC_2.3 symbol, it doesn't show up in the X driver, because it isn't linked against libc, however, the dri portion is. For some bizzare reason, redhat has decided to put a cvs version of glibc in their upcoming distro release, which you are aparently compiling against, the current release version of glibc is 2.2.5, more than 90% of users are probably using this version. *please* find a machine with a copy of glibc2.2, wait until glibc2.3 actually becomes a release to compile against it (or, if in the case of redhat, distribute it with your distro) --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
