Re: [Dri-devel] Ann: nightly snapshots resumed
Hi all They are only bleeding-edge snapshots because the DRI cvs HEAD no longer can produce binary compatible snapshots. All new snapshots require to download and install XFree86-4.2.99.2 server from http://dri.sourceforge.net/snapshots/extras/ . The 'install.sh' script attempts to determine your XFree version but this may still be buggy. Please report any problems with that. OK, just took it. First, the script really determines the version - but allows to proceed. I think it should break unconditionally at this point. Also, X server from ../extras just does not work. It break with signal 11.:( Same thing happens after installing dri drivers - this just makes no difference. I use plain XFree from RH8.0 (sure, everything is gcc 3.2-built). Any simple explanations? Regards, Sergey --- 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] cmpxchg [Was: Slack 8.1 Radeon 8500 64MB]
On Thu, 2002-10-31 at 21:59, Alan Hourihane wrote: That's debateable. In current kernels, if it's not defined you've more than likely built your kernel with i386 rather than i486 or later, because building for i486 or later automatically turns on CONFIG_X86_CMPXCHG. I understand that i386's don't have that instruction. Correct. DRI can still chose to build itself with that instruction and optionally also use an exception handler or check the actual CPU itself (eg when loading the module) --- 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
Sergey, On Fri, Nov 01, 2002 at 01:01:20PM +, Sergey V. Udaltsov wrote: Hi all They are only bleeding-edge snapshots because the DRI cvs HEAD no longer can produce binary compatible snapshots. All new snapshots require to download and install XFree86-4.2.99.2 server from http://dri.sourceforge.net/snapshots/extras/ . The 'install.sh' script attempts to determine your XFree version but this may still be buggy. Please report any problems with that. OK, just took it. First, the script really determines the version - but allows to proceed. I think it should break unconditionally at this point. Also, X server from ../extras just does not work. It break with signal 11.:( Same thing happens after installing dri drivers - this just makes no difference. I use plain XFree from RH8.0 (sure, everything is gcc 3.2-built). Any simple explanations? Oops... I completely forgot about mach64! Both mach64 and s3virge snapshots have nothing to do with this craze, and require no X server update (probably the contrary, as you have experienced). Unfortunately the install.sh script is the same and it will complain unless it uses a new version. I'll have to fix this, probably by using a seperate install.sh for mach64, or by specifing the necessary XFree86 version on the package describing file. José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- 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
I'll have to fix this, probably by using a seperate install.sh for mach64, or by specifing the necessary XFree86 version on the package describing file. Great. But why X server from 2.99.1 is not compatible with mach64?? I though I should not break things at least. Why does it? Anyway, I'll try mac64 driver with old XFree and report. Actually, about a week ago I tried mach64 snapshots on my new RH80 and noticed some instability - it crashed at some random points (not too frequently but still annoying). Unfortunately I could not notice any pattern in these crashes. Anyway, I will take the new snapshot and try. -- Sergey --- 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, Nov 01, 2002 at 01:50:38PM +, Sergey V. Udaltsov wrote: I'll have to fix this, probably by using a seperate install.sh for mach64, or by specifing the necessary XFree86 version on the package describing file. Great. But why X server from 2.99.1 is not compatible with mach64?? I though I should not break things at least. Why does it? I don't recall exactly what are the problems that cause binary incompatability. In any case, when XFree 4.3.0 is released, or probably before that, mach64 will be merged in the trunk and this will no longer be an issue. Anyway, I'll try mac64 driver with old XFree and report. Actually, about a week ago I tried mach64 snapshots on my new RH80 and noticed some instability - it crashed at some random points (not too frequently but still annoying). Unfortunately I could not notice any pattern in these crashes. Anyway, I will take the new snapshot and try. Ok. Thanks. José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- 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] Ann: nightly snapshots resumed
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. 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] 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] Issues w/Viewperf 7 drv-08?
Ian Romanick wrote: I'm running Viewperf for the first time. The drv-08 test doesn't look right to me using the R100 driver. For most of the test, the screen is totally black. When there is something on the screen, it looks like the far clip-plane isn't set quite right. It does NOT look like this w/LIBGL_ALWAYS_INDIRECT set. Ideas? Ian, I haven't downloaded viewperf 7 yet. Can you detail your experiences building running it apart from this bug? IE: Is it going to be a pita to get running, and if so, any helpful hints? 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] 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
[Dri-devel] Re: [Xpert]Savage and nVidia DRI drivers
José Fonseca wrote: Actually my main interest is the learning experience of making a DRI driver from ground up - experience which I plan to share by writing a thorough HOWTO describing the steps and explaining the working of a driver from the high-level structure to the low-level implementation details. (You already can see the very first writings on http://dri.sf.net/doc/howto/) Great! -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- 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] tdfx driver for voodoo 5 5500 and SLI
My question is about the voodoo and SLI. I'm a user of voodoo 5 5500 board and i love this board. So, i'm (and most of 3dfx users with linux) have much interess to see SLI work in linux. Observing the list of devels, my conclusion is: the radeon devel is much more implemented in relation as other chipsets. Why the radeon developers don't donate 30 minutes per day (or per week) to colaborate with SLI work?? The users of 3dfx with don't have much programer skills become very happy with yours atitude. Thanks for the drivers!! and have a nice day!! (sorry for my english, so this is not my native language) --- 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] texmem branch CVS stale lock?
I tried several times today to download the texmem-0-0-1 branch. Each time, when it reaches /cvsroot/dri/xc/xc/extras/x86emu/include, I get the message cvs server: [12:53:47] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/extras/x86em/include It then prints the same message at every minute. Could somone with the appropriate priveledges check if there is a stale lock in that directory and remove it (if that is in fact the problem)? Thank you, Jonathan Thambidurai --- 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] tdfx driver for voodoo 5 5500 and SLI
Felipe, On Fri, Nov 01, 2002 at 04:18:31PM +, Felipe Bugno wrote: My question is about the voodoo and SLI. First I would like to point out that I don't fully understand what you mean with SLI (Scan Line Interleave I suppose) and its implications with the voodoo driver. Spite of that, the comments below still hold. I'm a user of voodoo 5 5500 board and i love this board. So, i'm (and most of 3dfx users with linux) have much interess to see SLI work in linux. Observing the list of devels, my conclusion is: the radeon devel is much more implemented in relation as other chipsets. There are several reasons for that: - ATI has funded the radeon driver development in the past - The Weather Channel is funding the Radeon 8500 development - The radeon family is recent so it has a large userbase, and therefore, more people willing to help _developing_ Why the radeon developers don't donate 30 minutes per day (or per week) to colaborate with SLI work?? You're making the wrong question. The support for more cards isn't solved by reorganizing how the existing developers spend their time. Instead, it will only be solved by having _more_ developers. I would estimate that roughly it takes about 6 month-man full-time to make a full DRI driver. Consider that most of we only do this on part-time and how many developers we are on total to see how difficult it is to support all the cards. So the question you should be asking is why of all those 3dfx and linux users which have so much interess in seeing SLI working in Linux, not a single one steped forward to do it so far... Don't forget that the developers are also users. The users of 3dfx with don't have much programer skills become very happy with yours atitude. I'm sure they would. But they are no better than the other chips users (many of whom don't have no 3D support on linux whatsoever), and in the end, its the developers' will that really matters. Thanks for the drivers!! and have a nice day!! I'm sorry I can't be of much help to you. Regards, José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- 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] Multiple PCI Radeon AIW
After looking at the source, support for multiple cards is only enabled in the tdfx DRM yet. The attached hack might serve as a quick'n'dirty way to find out the next problem. :) I added in the #define from the patch. When I insmod, it now sees both cards. I get something like: [drm] Initialized radeon 1.6.0 20020828 on minor 0 [drm] Initialized radeon 1.6.0 20020828 on minor 1 ( Here's the next problem :) ) X, however, doesnt work. I get 1 blank screen and one with crazy lines zipping around. both cards are seen by X now: (II) RADEON(0): [drm] created radeon driver at busid PCI:0:9:0 ... (II) RADEON(1): [drm] created radeon driver at busid PCI:0:13:0 ... but then I get (II) RADEON(1): X context handle = 0x0001 (II) RADEON(1): [drm] installed DRM signal handler (II) RADEON(1): [DRI] installation complete (II) RADEON(1): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(1): [drm] Mapped 32 vertex/indirect buffers (EE) RADEON(1): RADEONDRICPInit: CP start -1007 (EE) RADEON(1): RADEONCPGetBuffer: CP GetBuffer -1007 (EE) RADEON(1): GetBuffer timed out, resetting engine... (EE) RADEON(1): RADEONCPGetBuffer: CP reset -1007 (EE) RADEON(1): RADEONCPGetBuffer: CP start -1007 (EE) RADEON(1): RADEONCPGetBuffer: CP GetBuffer -1007 (EE) RADEON(1): GetBuffer timed out, resetting engine... (EE) RADEON(1): RADEONCPGetBuffer: CP reset -1007 (EE) RADEON(1): RADEONCPGetBuffer: CP start -1007 (EE) RADEON(1): RADEONCPGetBuffer: CP GetBuffer -1007 (EE) RADEON(1): GetBuffer timed out, resetting engine... and so on. The full log is at http://www.eyetap.org/~fungja/radeon/XFree86.0.log.dualradeon -James --- 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] texmem branch CVS stale lock?
On Fri, Nov 01, 2002 at 04:04:45PM -0500, [EMAIL PROTECTED] wrote: I tried several times today to download the texmem-0-0-1 branch. Each time, when it reaches /cvsroot/dri/xc/xc/extras/x86emu/include, I get the message cvs server: [12:53:47] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/extras/x86em/include It then prints the same message at every minute. Could somone with the appropriate priveledges check if there is a stale lock in that directory and remove it (if that is in fact the problem)? There's basically nothing that can be done. This happens from time to time, and the only cure seems to be to wait. :( -- 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] texmem branch CVS stale lock?
On Fre, 2002-11-01 at 22:04, [EMAIL PROTECTED] wrote: I tried several times today to download the texmem-0-0-1 branch. Each time, when it reaches /cvsroot/dri/xc/xc/extras/x86emu/include, I get the message cvs server: [12:53:47] waiting for anoncvs_dri's lock in /cvsroot/dri/xc/xc/extras/x86em/include It then prints the same message at every minute. Could somone with the appropriate priveledges check if there is a stale lock in that directory and remove it (if that is in fact the problem)? CVS locks aren't branch specific, it's always the same repository files. The only thing that can be done is to submit a support request at https://sourceforge.net/tracker/index.php?group_id=1atid=21 , which I've done now (#632332). -- 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
