Typo in documentation?
The building guide in the DRI wiki (http://dri.freedesktop.org/wiki/Building) states the following under section 1.3.: snip Note: libdrm installs to /usr/local/lib by default. To install in /usr/lib run: ./configure --prefix=/usr --exec-prefix=/ ---end-- For me this solution doesn't work, as it will install the pkgconfig-files into /lib/pkgconfig. Thus the subsequent build of the Mesa tree fails. Shouldn't it just be ./configure --prefix=/usr instead? At least that works for me (on debian unstable). If it is a typo, please fix it, as this can be _very_ frustrating if you're trying to build mesa following this guide. If I'm just too stupid and doing something wrong, I'm sorry to have bothered you. mfg Stefan - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Xserver crashing 2.4.22 kernel (Intel 82845G/GL)
[EMAIL PROTECTED] wrote: Hi, I have a MSI 845GL-P barebone, 00:02.0 VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated Graphics Device (rev 01) and do use it with 2.4.22, i830 and agpgart kernel modules and 4.3.0-0pre1v1 xfree86-xserver (debian package). Unfortunately the kernel crashes every few minutes. The problem is that it does not crash immediately, it continuously degenerates. Some programs start to behave crazy or simply disappear, and the kernel shows more and more malfunctions, like being unable to remove kernel modules or finding hard discs. I manged to get a trace once (see below), but I'm pretty sure it's useless, since this is not what's causing the problem. Are you sure you don't have faulty hardware? These symptoms sound like they might well originate from bad ram, bad cpu, bad harddrive, or maybe an overheated system. I am pretty sure that the combination of the xserver with this vga device corrupts kernel memory structures (many normal programs suddenly die with segmentation fault or with a kernel error message about mapping problems. When I finally get a Oops debug output, thing have already gone wrong. I first used the machine without i830 and agpgart modules, but this was even worse. So why do you think the DRI drivers are the reason then? Do you have any idea whether this is a known bug? regards Hadmut --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
Ronny V. Vindenes wrote: Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: [...] Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. just wanted to let you know that current cvs works ok for me with a 8500LE. so it seems that not all r200 cards / configurations are affected. (athlon xp, 2.6.0-test8, crt connected to normal vga-port, not dvi) --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Broken Xv in current trunk?
Hello, if I try to use Xv (via mplayer, or with xawtv using the v4l-module) with current cvs (trunk) the X server crashes. I'm using a r200-based card (Radeon 8500). When I check out cvs from just before the mergedfb-merge (i tried 2003-10-07, 4:30:00), I get no problems, so the merge might have broken something. Can anybody reproduce this? regards, Stefan --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS
Jonathan Warren wrote: I just purchased an ati 8500dv and would like to get the dir project and the gatos project running on my system. I am trying to identify what I need to do to make everything work together. AFAIK you can't have Gatos- and DRI-drivers at the same time. Both projects use different versions of the drm kernel module which are not compatible. I don't know if Gatos currently supports 3d-accel with r200-based cards, you'll have to check Gatos-documentation for that. I have read through the CVS documentation I can find and have pulled the src from cvs using the following commands. xfree86 CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs cvs -z3 co xc should I be using the xf-4_3-branch or any other branch? For DRI you don't have to check out any sources from xfree86 cvs. Everything you need is contained in DRI-cvs. DRI CVSROOT=:pserver:[EMAIL PROTECTED]:/cvsroot/dri cvs -z3 co xc Again is the default the correct branch to pull? that should do. --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Serious Sam: 2nd Edition crash
Martin Spott wrote: Michel D?nzer [EMAIL PROTECTED] wrote: You could try to set the environment variables RADEON_NO_CODEGEN, RADEON_NO_VTXFMT and RADEON_TCL_FORCE_DISABLE [...] BTW, I just aquired a Radeon9100 clone to see if serveral 'features' resemble the behaviour I'm used to see on my Radon7500. Infortunately they pretty much behave the same way: The card locks up under certain 'well known' conditions and FlightGear looks quite dark with TCL enabled. I'm now looking for a switch to disable TCL on the r200 based card but grepping the source code I did not find an equivalent to the above mentioned environment setting. R200_NO_TCL=1 should do the trick Did I miss it ? Martin. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Confusing..?
John S. Chalice wrote: I just last night downloaded the newest CVS from dri.sourceforge.net.. and tried compiling it.. it went smoothly.. no errors.. *BUT*.. none of the kernel modules were created.. for *any* of the video drivers listed in the host.def file.. Any ideas? well, you can always build them manually after compiling the rest: cd programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ make -f Makefile.linux MODULE.o and then as root: cp MODULE.o /lib/modules/`uname -r`/kernel/drivers/char/drm/ depmod -a where MODULE.o corresponds to the drm-driver you need regards, Stefan -- John S. Chalice --- 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] A question, about Rage128 and news in DRI
Willy Gardiol wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, few days ago i was trying to play ut2003 on my Rage128 but, off course, with no luck (s3c missing), is this feature one of the new things going to be implemented in the near future? VIA/S3 has been contacted several times already, whether they'll allow the integration of S3TC-support in the DRI. Unfortunately they never answered. So it's not very likely that you'll S3TC in DRI in the near future. Things might change some time, if you're lucky, but I doubt it. If you update ut2k3 to the latest version you'll be able to play it even without S3TC-support, however. But I seriously doubt that you can play ut2k3 with a r128 anyway... regards, Stefan Thnaks, and good work. --- 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] trunk (r200): Q3A ID LOGO intro (cinematics) stutteringSOLVED
Ian Molton wrote: On Sat, 11 Jan 2003 22:51:33 +0100 Dieter Nützel [EMAIL PROTECTED] wrote: No, it's a Q3A 1.32 bug fixed in 1.32b. OK, I'm downloading now. where do I get 1.32b? quake3arena just says 1.32 ftp://ftp.idsoftware.com/idstuff/quake3/linux/linuxq3apoint-1.32b.x86.run --- 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
[Dri-devel] Re: [Dri-users] New ATI FireGL drivers announced
Frank Steiner wrote: Alexander Stohr wrote: The drivers should run on Linux/x86 with glibc 2.2, some common kernel modules do come precompiled and a build environment for gcc2.96 and gcc3.2 is included, thus making that drivers compatible with e.g. RedHat(R) Linux(R)/x86 8.0 or 7.3 versions. Hmm, according to http://www.gnu.org/software/gcc/releases.html there is no gcc 2.96 version, just 2.95. However, trying to compile the modules with gcc 2.95 on my SuSE 7.3 fails with In file included from firegl_public.c:219: patch/drivers/char/drm/drm_proc.h: In function `FGLDRM_proc_init': patch/drivers/char/drm/drm_proc.h:87: parse error before `)' firegl_public.c: In function `firegl_proc_init': firegl_public.c:287: parse error before `)' firegl_public.c: In function `firegl_proc_cleanup': firegl_public.c:335: parse error before `)' firegl_public.c: In function `firegl_stub_open': firegl_public.c:361: parse error before `)' firegl_public.c: In function `firegl_stub_getminor': firegl_public.c:398: parse error before `)' firegl_public.c: In function `firegl_stub_register': ... and many more lines like this. Anyone got the driver compiled with gcc 2.95? nope, i got the same messages. I ended up compiling with gcc-3.2, which worked but i didn't get dri running with ati's driver... cu, Frank --- 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] mesa-4-1-branch testing...
Hi! I've done some more testing on the mesa-4-1-branch (checked out and compiled yesterday) All in all everything runs quite nicely and stable. I successfully tested: -quake (quakeforge-0.5.2): works, but quite sluggish, especially when there are lots of light effects -quake2 (quakeIIforge 0.1): works stable and fast, but only with dynamic lighting disabled, as suggested earlier with dynamic lighting and multitexturing it's hardly playable -quake3 (1.32): nice, fast and stable ;-) -return to castle wolfenstein (1.3): now works stable for me, as far as I can tell, but performance is a bit weird: it's fast most of the time, but sometime framerates drop to almost 0 for a little while, mostly when opening doors, entering new rooms etc. (but that could also be related to low system ram, i only got 256 MB, and I'm playing at max. details) -tuxracer -tuxkart -gltron -glxgears ;-) -half-life (using winex): seemed stable, but not very fast. switching on your flashlight for example hugely affects performance (goes down to ~5fps or s.th.) Apps that I had problems with: -flightgear: after some left- and right-clicking in the fgfs-window my keyboard wasn't responsive anymore. This happened once only, but i didn't really test fgfs, as i don't have a clue about how to play it :) General prolems/issues: Changing resolution in wolfenstein, q3a, q2 etc. does not work. It will not crash the box, but give garbage pictures on the screen. Software-TCL produces flickering/missing textures in wolfenstein (q3a is fine) I did the testing with a r200 (8500 QL), amd athlon XP, via kt266a-mainboard, using debian-unstable and linux-2.4.20-rc1. It seems that now AGP4x is also fairly stable for me, but I have to do some longer testing do definitely confirm this, most of the testing was done at AGP1x. Fastwrites are disabled, pageflipping is enabled Thanks for the nice work, Stefan --- 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] Radeon 8500 / R200 status?
Major A wrote: I heard a while ago that some company was sponsoring the development of a proper DRI driver for the ATI R200 -- can someone briefly update me as to what the status of that driver is in the latest release and in CVS? Is it a worthy replacement (in OpenGL performance and stability) for the ATI binary-only driver? The development of the r200 drivers is sponsored by The Weather Channel. Both 2D and 3D should basically work in the latest X release. 3D can be somewhat unstable, if you're unlucky. But I just tried latest mesa-4-1-branch CVS, and it seems to work very well (no crashes in return to castle wolfenstein anymore). I haven't used ATI's proprietary drivers for quite a while now, so I can't really compare. Performance is still a bit sloppy, but I hope that'll improve. As a summary, I think you should give the drivers a try. 2D support is better IMHO, as it includes XV-support. I don't know the status of the multi-head capabilities of the open-source drivers compared to the closed ones. Thanks a lot, Andras --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa-4-1-branch
Adam K Kirchhoff wrote: On Tue, 19 Nov 2002, Brian Paul wrote: Adam K Kirchhoff wrote: So I decided to give the mesa-4-1-branch a whirl and do some testing... I grabbed it from CVS: $ cvs -z3 co -r mesa-4-1-branch xc And then I did a Make world. Unfortunately, it didn't get very far: make[5]: Entering directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a .emacs_* tags TAGS make.log MakeOut #* /bin/sh: -c: line 1: syntax error near unexpected token `;' make[5]: *** [clean] Error 2 make[5]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86/input' make[4]: *** [clean] Error 2 make[4]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver/hw/xfree86' make[3]: *** [clean] Error 2 make[3]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs/Xserver' make[2]: *** [clean] Error 2 make[2]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc/programs' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/home/adamk/mesa-4.1-branch/xc/xc' Any idea what's going on with that? Do a CVS update again in case you didn't get my latest check-ins. -Brian Still no go. Dies at the same place with the same error. I just checked it out (2h ago), and it compiled fine. It also seems to run quite nicely. No crashes with wolfenstein or q3a, but I only tested quickly. you could try to erase your local cvs-copy and check it out completely, maybe that helps? btw: the flickering/missing textures with software tcl issue is still present after the merge from trunk, so it's probably an issue with the mesa-4.1 respectively mesa-5.0 code. Not that it really matters a lot, though... regards Stefan Adam --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI bleeding edge and video memory
Jacek Pop?awski wrote: I've installed 4.2.99 extras and tdfx driver from directory bleeding edge: (WW) TDFX(0): Failed to set up write-combining range (0xe800,0x200) (II) TDFX(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0xbd00 (II) TDFX(0): Changing back offset from 0x00573000 to 0x00572000 (II) TDFX(0): Not enough video memory available for textures and depth buffer and/or back buffer. Disabling DRI. To use DRI try lower resolution modes and/or a smaller virtual screen size My Vooodo3 has 16MB of video memory. I've decreased resoulution to 640x480, but it didn't help. Everything works well on 4.2.0 and binary driver from 20021022. Full log attached. From your log: (--) TDFX(0): Virtual size is 1920x1440 (pitch 1920) There is a small bug that appeared on the list already some time ago, where the 2D-code thinks it's using high virtual resolutions. Back then David Dawes wrote in http://sourceforge.net/mailarchive/message.php?msg_id=2328996 : It's a side-effect of the recent RandR additions. It should be resolved before too long. In the meantime, you can specify the virtual size explicitly. Could you try if that helps? regards Stefan --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 9000 support ?
David Balazic wrote: Hi! How is the Radeon 9000(/pro) support ( for linux/x86 ) ? 2D and 3D should work (there were some patches and some discussions about 9000-support on the mailing-list recently, check the ml-archives) That is the rv250 chip, right ? yes Is radeon 9000 much/any faster than 8500 ? Don't be misled by the name 9000! The Radeon 9000 is slower than the 8500 Is the 8500 ( r200 ? ) better supported in xfree86/dri ? probably, as it already got more testing I would not be asking these questions , if the HW support status pages were good ;-) Regards, david --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Half OT: Radeon Framebuffer SVideo
Ayahuasca wrote: Hi all. I know this is not exactly the perfect list for this, but then again it does have a lot of people who know how the Radeon ticks, so... I have been using the Radeon Framebuffer driver in the kernel. I use it mainly for mplayer, as my card (VIVO) only puts a signal out the SVideo cable when I boot to a framebuffer console. If someone has an alternate method of turning on TV-out (maybe even in X) then please tell me. I only tested it very briefly, but TV-out also worked on my R200 (Radeon 8500) without fb-console. Here's what I did: turn computer off plug in s-video cable and connect it to tv (tv-grabber card for my test) turn computer on mplayer -vo vesa:vidix movie then the movie was displayed on both my regular monitor and tv-out Anyway, I just changed motherboards (long sad story) and now if I try to boot to a Radeon framebuffer with the SVideo cable attached, the monitor goes into power-saving mode, and the signal gets cut from the TV as soon as the framebuffer mode is activated. It looks like a sync-out-of-range problem. I have tried EVERY vga=xxx mode. Sometimes the monitor will stay on, but never the TV. It works fine with the standard vesa framebuffer, but I am also trying to get Enlightenment-0.17 working through DirectFB, so I'd rather not give up on the Radeon drivers just yet... Anyone know what's happening / how to fix it? Thanks! Dan --- 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] Flickering/missing textures in mesa-4-1-branch (r200, software-tcl)
Hi there, If I set R200_NO_TCL=t I get flickering and/or missing textures in Return to Castle Wolfenstein. With hw-TCL, everything looks fine. With current dri-trunk rendering is fine with both hw- and sw-TCL. I'm using a Radeon 8500QL and mesa-4-1-branch from Monday. Can anyone reproduce this? In case you're interested, there's a screenshot(329k) here: http://homepages.uni-regensburg.de/~las23033/wolf_notcl.png Regards, Stefan --- 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] Blank screen when switching VT
[EMAIL PROTECTED] wrote: Hi, i'm using a kernel 2.4.20-pre11 with a radeon module compiled from CVS. I have a radeon 8500 LE (r200 QL), and every time i want to switch from X to VT, i've got a blank screen and my computer is frozen... This means i can't halt|reboot properly as i can't reach console mode... I'm wondering if someone has a clue You can cleanly shutdown/reboot your box by using the shutdown-command. As root type: shutdown -h now for system halt, shutdown -r now for reboot, you can also use the shortcuts halt and reboot about that? I've set some optimisation flag when compiling (-march=athlon-tbird -O2 -pipe), can this pose a problem? Thanks, Marc --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Crashes/Lockup with current cvs (trunk) on r200
Hi! I'm currently using cvs-code from the dri-trunk from today. I got several crashes of the xserver (system was still running stable). Once, however, I got a complete lockup. Examining the log-files after rebooting, I found tons of these messages: in XFree86.0.log: - *** be the reason for the server aborting. Fatal server error: Caught signal 4. Server aborting [...] When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file /var/log/XFree86.0.log. Please report problems to [EMAIL PROTECTED] (EE) RADEON(0): RADEONWaitForIdleCP: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONWaitForIdleCP: CP reset -1007 (EE) RADEON(0): RADEONWaitForIdleCP: CP start -1007 (EE) RADEON(0): RADEONWaitForIdleCP: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONWaitForIdleCP: CP reset -1007 (EE) RADEON(0): RADEONWaitForIdleCP: CP start -1007 (EE) RADEON(0): RADEONWaitForIdleCP: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONWaitForIdleCP: CP reset -1007 (EE) RADEON(0): RADEONWaitForIdleCP: CP start -1007 [and so on and so on...] -- in /var/log/kern.log: Oct 24 16:46:24 harkpabst kernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held Oct 24 16:46:24 harkpabst kernel: [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held Oct 24 16:46:24 harkpabst kernel: [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held Oct 24 16:46:24 harkpabst kernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held Oct 24 16:46:24 harkpabst kernel: [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held Oct 24 16:46:24 harkpabst kernel: [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held Oct 24 16:46:24 harkpabst kernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held [and so on and so on...] - Note: I was not running any GL-apps at the time the crashes occured. DRI- and GLX-modules are loaded, however. I attached the complete server-log, in case that helps. Regards Stefan --- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Crashes/Lockup with current cvs (trunk) on r200
Stefan Lange wrote: [...] I attached the complete server-log, in case that helps. forgot to add the attachment, as usual... XFree86.0.log.old.bz2 Description: Binary data
Re: [Dri-devel] Mesa 4.1 branch
I cvs-updated both Mesa and mesa-4-1-branch today, and I don't get any more FPE's with R200_NO_TCL=1. Thanks! Stefan --- 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] Mesa 4.1 branch
[...] hmm, that's odd. I still get floating point exceptions for almost every GL-app. with TCL disabled. Demos that _do_ work with TCL disabled include: clearspd, drawpix, gamma, glinfo, lodbias, readpix, winpos Maybe this can give you a clue, why some are working and some aren't? Could I have messed something up during checking out/compiling/installing that is causing these FPE's? Can you run with gdb and find where the FP exception is happening? Well, first I gotta admit that I don't have any experience in debugging, so this log might be completely useless. If that's the case, I'd appreciate if anyone can give me a quick howto in basic debugging. harkpabst [../MESA-CVS/Mesa/demos] $ export R200_NO_TCL=1 harkpabst [../MESA-CVS/Mesa/demos] $ gdb ./gears GNU gdb 2002-08-18-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-linux...(no debugging symbols found)... (gdb) run Starting program: /mnt/hdc1/benutzer/src/dri/MESA-CVS/Mesa/demos/gears [New Thread 1024 (LWP 27531)] Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 1024 (LWP 27531)] 0x406452df in _mesa_test_os_sse_exception_support () from /usr/X11R6-DRI/lib/modules/dri/r200_dri.so (gdb) c Continuing. disabling TCL support Program received signal SIGFPE, Arithmetic exception. 0x4064872a in _mesa_sse_transform_points3_general () from /usr/X11R6-DRI/lib/modules/dri/r200_dri.so (gdb) bt #0 0x4064872a in _mesa_sse_transform_points3_general () from /usr/X11R6-DRI/lib/modules/dri/r200_dri.so #1 0x08055e10 in ?? () #2 0x40644e01 in init_vertex_stage (ctx=0x805ba68, stage=0x81da6cc) at t_vb_vertex.c:286 #3 0x4060b704 in _tnl_run_pipeline (ctx=0x805ba68) at t_pipeline.c:155 #4 0x40653ddc in r200WrapRunPipeline (ctx=0x805ba68) at r200_state.c:2088 #5 0x40608eb5 in _tnl_run_cassette (ctx=0x805ba68, IM=0x81e14a0) at t_imm_exec.c:400 #6 0x405fe5f4 in execute_compiled_cassette (ctx=0x805ba68, data=0x81f372c) at t_imm_dlist.c:377 #7 0x404cd6a0 in execute_list (ctx=0x805ba68, list=1) at dlist.c:4218 #8 0x404d0556 in _mesa_CallList (list=1) at dlist.c:5095 #9 0x4055ac4a in neutral_CallList (i=1) at /mnt/hdc1/benutzer/src/dri/MESA-CVS/Mesa/src/vtxfmt_tmp.h:339 #10 0x0804cad7 in draw () #11 0x40030d55 in processWindowWorkList (window=0x64) at glut_event.c:1297 #12 0x4019a0bf in __libc_start_main () from /lib/libc.so.6 (gdb) quit A debugging session is active. Do you still want to close the debugger?(y or n) y harkpabst [../MESA-CVS/Mesa/demos] $ Do you require backtraces from more different demos? One other thing that might be worth noting: Starting quake3.x86 from text console within gdb (switch to vt with C-M-F1, export DISPLAY=:0, gdb ./quake3.x86, run, c) does work with TCL disabled, for some reason. I attached some info about my system (cpuinfo, compiler-version etc.) Stefan -Brian sysinfo.bz2 Description: Binary data
Re: [Dri-devel] Mesa 4.1 branch
Brian Paul wrote: [...] I did some testing with the mesa-4-1-branch today on my r200. Compiling was less trouble than I expected, everything was pretty much straight forward ;-) I'd appreciate it if people could start testing this branch, esp the drivers I haven't tested. One thing in particular to check is the Mesa/demos/readpix program - make sure front/back buffer rendering is working. That's something that I've had to change in all the drivers. I don't know what exactly readpix is supposed to do, but I think it works fine. Switching between front and backbuffer doesn't affect the displayed pictures. The benchmark result is: Benchmarking... Result: 325 reads in 4.009000 seconds = 2956697.430781 pixels/sec My experiences from testing: Wolfenstein (single-player): works, about same speed as dri-trunk, but not completely stable (exited with Signal 4 in one run, and Signal 11 in another, and once I got a complete lockup of the system) 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. small stuff like gl-screensavers, mesa-demos seems to run fine one more thing: If I disable hardware-TCL (R200_NO_TCL=1), then some GL-apps won't start ( Signal 8 / FPE ). At least q3a, wolfsp and gears are affected, probably others too. Disabling hw-TCL does work with current trunk-code for me. My system is a AMD 1800+ on a KT266A-mobo, with a Radeon 8500 QL, linux-2.4.19, agpmode is set to 1, page-flipping is enabled [...] -Brian --- 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] Mesa 4.1 branch
Keith Whitwell wrote: Russ Dill wrote: 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 That makes sense. The speed problem comes from agressively throttling glClear() operations. Q3 does multiple clears of the backbuffer for drawing the little floating head and I don't know what else in the status bar. So, I expect the speed to go up after a trunk merge. I just checked, that's exactly the case: With cg_drawStatus 0 I'll get 50 FPS also with pre-October-11 code. It seems like those on-screen-display things are indeed causing this effect. Drawing or not drawing the gun doesn't make a change for me, however. Keith --- 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] Mesa 4.1 branch
Brian Paul wrote: Brian Paul wrote: Stefan Lange wrote: My experiences from testing: Wolfenstein (single-player): works, about same speed as dri-trunk, but not completely stable (exited with Signal 4 in one run, and Signal 11 in another, and once I got a complete lockup of the system) 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. I made the branch on Oct 9. I'll do a merge from the trunk in a bit. Hopefully that'll clear up the speed problem. The merge is done. OK, so I just updated from CVS and recompiled. as expected: the speed problem in q3a is solved ;-) small stuff like gl-screensavers, mesa-demos seems to run fine one more thing: If I disable hardware-TCL (R200_NO_TCL=1), then some GL-apps won't start ( Signal 8 / FPE ). At least q3a, wolfsp and gears are affected, probably others too. Disabling hw-TCL does work with current trunk-code for me. I'll test this after updating from the trunk. Setting R200_NO_TCL works for me - no signals or FP exceptions. However, with R200_NO_TCL I'm seeing some flashing/missing textures in RTCW. hmm, that's odd. I still get floating point exceptions for almost every GL-app. with TCL disabled. Demos that _do_ work with TCL disabled include: clearspd, drawpix, gamma, glinfo, lodbias, readpix, winpos Maybe this can give you a clue, why some are working and some aren't? Could I have messed something up during checking out/compiling/installing that is causing these FPE's? I attached the output of glxinfo, in case that's any helpful. Regards, and thanks for your quick help and patience, Stefan -Brian glxinfo.bz2 Description: Binary data
Re: [Dri-devel] Re: [Dri-users] Radeon 8500 woes...
[...] Well, I managed to run the newest binary snapshots by installing the newest r200-snapshot (yesterday) and copying radeon_drv.o from 0924 into my XFree-dir. It works. I even have Xv. That leads me to another question: what exactly is in radeon_drv.o? It's the 2D-driver, the 3D-parts lie in r200_dri.so (or radeon_dri.so for r100) Bye, Adam. --- 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] trunk/r200: IRQs seems working, now. But DRM buildfor 2.5.40+ not.
Dieter Nützel wrote: OK, the IRQ stuff seems working currectly on my dual Athlon SMP box. I can second that, q3a works fast and stable for me, too, now! The 50-FPS-limit I used to experience is gone, and overall performance is a lot better, too demo four now gives me about 48 FPS (1280x1024@24bit, max. details, geometry high) gears is also running well (2200 FPS, with low cpu load) With and without setenv R200_NO_USLEEPS 1 I get the same numbers for Q3A. Q3A 1.32, 640x480x24 window on a 1280x1024x24 desktop, demo four: with sound: 130.3 fps wthout sound: 138.6 fps r_smp 1 quake3.x86 block, keyboard and mouse wouldn't release X server shutdown clear it --- 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] New snapshots available - please test (Was: Snapsfor gcc3, glibc-2.2)
[...snip...] This assuming, of course, that these snapshots are indeed the promised holly graal. Please test. seem to work fine for my system (i tried the r200-package, on debian unstable, gcc is 2.95.4 on my system) nice work José Fonseca --- 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)
I'm getting quite similar results: with xmms running in background: ~150 FPS with xmms paused: ~130 FPS after i unpause xmms, FPS will drop down very low (~10 FPS or s.th.) for about 1 or 2 seconds (system load is almost 100% during that period), and then go up to 150 again (with low sys-load) after updating today, gears is up at 2200-2300 FPS again. Pausing/unpausing an xmms running in the background, or also changing volume still gives me massive slowdowns for about 1 s, after that performance goes up to normal again. I'm using a CMedia-PCI-Sound-card (CM8738), with kernel oss driver, if that matters. performance in q3a is also very poor for me at the moment (but it seems fairly stable (played for about 20 min. without lockup/crash, which is better than i used to get with earlier driver builds) q3a-performance is still as low as yesterday. one thing that might be interesting: framerate in q3a seems to never get above 50. it's mostly around 20-40 (all settings at maximum, 1280x1024). com_maxfps is at the default value of 85, and monitor vsync is 75 Hz. So I'm wondering why the framerate doesn't go beyond 50? anyway, keep up the nice work, driver are getting better every day, thanks ;-) system: 8500 LE, XP1800+, KT266A-mobo, dri-cvs (trunk) from 30 min ago, linux-2.4.19 (vanilla), debian unstable --- 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] Xv and OpenGL -- new module idea
Alex Deucher wrote: I'm pretty unfamiliar with OpenGL programming. I have an idea for an xfree module that I suspect would not be too hard to implement, but I wanted to get some other opinions on it. What I'd like to do is create a module called perhaps ogl-xv or glx-xv that would provide a generic Xv adapter on the front end and on the back end would implement it using openGL calls to basically create an RGB or YUV texture to render the video to. this would have the advantage of acceleration on cards with accelerated 3D, and would provide generic Xv support to cards lacking an overlay engine by using SW mesa, and it could provide for more than one Xv adapter, so you could theoretically have more than one Xv at a time. Disclaimer: I'm _not_ a programmer, and I don't know anything about GL or XV, so this is merely a blind guess: you might want to look at the code of mplayer's -vo gl and -vo gl2, which provide opengl-video-overlays, to get started regards Stefan Alex --- 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
Re: [Dri-devel] r200 CVS, profiling
Franklin Kingma wrote: Second, yesterdays r200 build seems to have some profiling display on the upper left on the screen consisting of a white bar and some green squares. Is there any info about what this means (or where it might be disabled)? it does the same at my freebsd system with yesterdays build... same here (Athlon XP, linux-2.4.19-rc2) the square are flickering here all gl-apps i have tested seem to be affected 2 screenshots can be found here to illustrate: http://homepages.uni-regensburg.de/~las23033/atlantis.png http://homepages.uni-regensburg.de/~las23033/gears.png regards Stefan --- 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] radeon mmio area size
Keith Whitwell wrote: Can someone out there check this quickly? In radeon.h in the 2d driver, the size of the radeon mmio area is defined as 0x8 - however, on my r200 at least, /proc/pci shows the area as being 1/8th that size: Bus 1, device 0, function 0: ... (omitted) ... Non-prefetchable 32 bit memory at 0xff5f [0xff5f]. Can someone with a radeon installed make the same check? mine says: $cat /proc/pci [...] Bus 1, device 0, function 0: VGA compatible controller: ATI Technologies Inc Radeon QL (rev 0). IRQ 11. Master Capable. Latency=32. Min Gnt=8. Prefetchable 32 bit memory at 0xd800 [0xdfff]. I/O at 0xc000 [0xc0ff]. Non-prefetchable 32 bit memory at 0xe100 [0xe100]. Stefan that's a r200 (8500QL aka LE) --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Fast Writes
[...] Which makes perfect sense for Michal Kozlowski problem, old chipset (no / buggy fast write support) and new graphics card (with fast write support). This issue is also present for me, I get the same behaviour (X-server crashes, and blanks the screen) on my box, even though I've got a relatively new chipset (it's a Via KT266A) Maybe it's a general problem with Via Chipsets. Has anybody successfully tested these drivers with fast write enabled in the bios? If yes, what mainboard chipset are you using? --- 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] good buy?
Ian Molton wrote: Is the Hercules 3D Prophet 8500 a good card? (is the 2D stable at 1600x1200, unlike my 7500 VIVO which has a noticeable 'noise' so that vertical lines arent smooth, but somewhat rough looking) i think it's a fairly decent one. but there are rumors that some hercules 8500 cards on the market only have one ramdac (i.e. no possibility for dual-head), so I'd double-check that before buying Also keep in mind that the Hercules 8500 is only clocked at 240MHz memory clock, some others have 250MHz. unfortunately there's such a load of 8500 OEM boards, it's a bit hard not to get confused... I've got a FIC card (8500LE), which seems to be 100% identical with the original ati-boards (no traces of FIC in the bios-strings, ati-logos on the board, covered with fic-stickers, etc.). I take that as a plus, because that way chances are best to get maximum compatibility with the retail cards. Mine was even the cheapest on the market that time i bought it, so maybe lookout, if you can find this model somewhere will it work 2D on a stock X 4.2 ? yes what framerate does the beta DRI accel for it give in Quake3 ? i only tested on a selfmade demo (not an official one), but the relative numbers should give you an idea nevertheless: win98: ~150-160 fps X, firegl drivers: ~130 fps X, r200-branch: ~80 fps keep in mind that the r200 branch is very new, so there's surely room for improving the performance on my system, however, q3a will usually crash after some minutes of playing, other people have reported that it runs stable, so your mileage may vary All questions I must know answers to ;) Might have a chance to upgrade soon! (like, tomorrow, so answer me quick please :-) --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: I found the answer I was looking for.
Mike Mestnik wrote: If you man ascii, which on a hunch I did, you will find that... Hex Char 51Q 57W 4CL 45E Hence QW 0x5157, QL 0x514C, and the LE would have Product ID 0x4C45 this product ID is not on file. I'll look into why the Xserver it equating 0x4C45 to 0x5157. I was working on having this all done kernel side, It has a pci database so there's no need for the Xserver to duplicate it. 5157 Radeon 7500 QW 1002 013a Radeon 7500 514c Radeon QL 1002 013a Radeon 8500 4c45 Rage Mobility M3 AGP (Should be LE, or 4d33(Not on file) Hmm, I wonder what else I'll find. Hi, as Eric already mentioned, LE is only the marketing name ATI and the OEM vendors use to distinguish the faster and slower versions of the 8500 boards on the market. Retail boards (core clock 275 MHz, mem clock 275 MHz) are usually just called Radeon 8500, whereas the cheaper versions (core clock 250 MHz, mem clock ~250 MHz, depending on the manufacturer) are called Radeon 8500 LE. I don't think this corresponds directly to the PCI-ID's My card is such a lower-clocked LE card. lspci -vvn gives me this: (...) 01:00.0 Class 0300: 1002:514c Subsystem: 1002:013a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at d800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at c000 [size=256] Region 2: Memory at e100 (32-bit, non-prefetchable) [size=64K] Expansion ROM at unassigned [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=47 SBA+ 64bit- FW+ Rate=x1,x2,x4 Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x1 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- In the X-log it's detected as a 8500 QL (X-log is attached, if it is of any help to you) regards Stefan XFree86 Version 4.2.0 (DRI trunk) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 January 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.19-pre10 i686 [ELF] Module Loader present 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/XFree86.0.log, Time: Thu Jul 11 08:06:21 2002 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout Simple Layout (**) |--Screen Screen 1 (0) (**) | |--Monitor miro 2085 (**) | |--Device Radeon 8500 (**) |--Input Device Generic Keyboard (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc104 (**) XKB: model: pc104 (**) Option XkbLayout de (**) XKB: layout: de (**) Option XkbVariant nodeadkeys (**) XKB: variant: nodeadkeys (**) Option XkbOptions grp:switch,ctrl:ctrl_aa,grp_led:scroll (**) XKB: options: grp:switch,ctrl:ctrl_aa,grp_led:scroll (==) Keyboard: CustomKeycode disabled (**) |--Input Device Generic Mouse (**) |--Input Device Generic Keyboard (**) XKB: rules: xfree86 (**) XKB: model: pc104 (**) XKB: layout: de (**) XKB: variant: nodeadkeys (**) XKB: options: grp:switch,ctrl:ctrl_aa,grp_led:scroll (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7110,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/100dpi/:unscaled,/usr/lib/X11/fonts/75dpi/:unscaled,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi (==) RgbPath set to /usr/X11R6-DRI/lib/X11/rgb (**) ModulePath set to /usr/X11R6/lib/modules (**) Option BlankTime 0 (--) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 ABI
Re: [Dri-devel] R200 video signal lost
Hi Michal! I'm also playing around with the r200-branch at the moment, and I've got better results than you (I tried both jose's snapshots and building from cvs). X starts up fine for me, and 3D also works to some extent (glxgears, glx-screensavers work for example, but q3a, wolf and so on crash after a few minutes of playing). I still got some trouble with Xv, sometimes it works, sometimes it doesn't, but that's another story... Other than that I haven't experienced any 2D errors. Did you take a look at /var/log/XFree86.0.log, maybe it gives you any interesting information why the server won't start (or why it blanks your screen) You could also try to checkout and compile the current cvs rather than using the binary snapshots, maybe that makes a difference. Also, what hardware are you using (mainboard chipset, model of the card, cpu ...)? Maybe the current driver works better on some chipsets than on others? Michal Kozlowski wrote: I guess I forgot to mention that I'm trying out the r200 dri drivers that Keith released a couple of days ago. No if I reboot and do not change my XF86Config not to load DRI then I get a lost signal. The only reason I'm trying DRI now is b/c of the new r200_dri driver, do I have something configured wrong to get the r200 driver running, seems to me like the radeon_drv should find the r200_dri automatically (radeon_dri.c line# 1310). My kernel mod is the one provided by r200-20020709-linux.i386.tar.bz2, no modifications. Cheers Mike On Wed, 10 Jul 2002, Mike Mestnik wrote: Yes, I had a simular problem, rebooted and every thing was fine. I got my kernel mod from cvs (and patched it heavily to support devfs) then I got the rest of DRM from http://dri.sourceforge.net/snapshots/radeon-20020710-linux.i386.tar.bz2 I have a 7500 QW though. I'l get my 8500 ought of that windowz box and run some tests, K. --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 video signal lost
Michal Kozlowski wrote: Hi Stefan, good to hear someone got it working. I'll give the r200-0-1-branch a shot, see if I can compile it and get it running. Would there be a problem if I had the radeon_dri modules still in the module/dri directory (I'll try removing it) if you recompile and do a make install, all the files that have been changed should be updated (r200_dri.so and radeon_dri.so have been updated for me at least) compiling from cvs shouldn't be a problem, I just followed the DRI Compilation Guide from the website and everything went fine (you might have to compile the kernel drm-module manually, but that's no trouble) snip Did you take a look at /var/log/XFree86.0.log, maybe it gives you any interesting information why the server won't start (or why it blanks your screen) /snip I posted in my first post, didn't want to clutter up the email in the reply, here is the last snippet of my log: (II) RADEON(0): [agp] AGP Texture map mapped at 0x4452c000 (II) RADEON(0): [drm] register handle = 0xe100 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): CP in BM mode (II) RADEON(0): Using 8 MB AGP aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 5 MB for AGP textures (II) RADEON(0): Memory manager initialized to (0,0) (1600,2514) (II) RADEON(0): Reserved area from (0,1200) to (1600,1202) (II) RADEON(0): Largest offscreen area available: 1600 x 1312 (II) RADEON(0): Reserved back buffer at offset 0xf5a000 (II) RADEON(0): Reserved depth buffer at offset 0x16ad000 (II) RADEON(0): Reserved 34816 kb for textures at offset 0x1e0 (==) RADEON(0): Backing store disabled (==) RADEON(0): Silken mouse enabled This is right before where XAA is suppose to load. snip yes, XAA is the next section in my log files, do yours just stop there? Also, what hardware are you using (mainboard chipset, model of the card, cpu ...)? Maybe the current driver works better on some chipsets than on others? /snip oops, okay I'm running an AMD thunderbird 1 Ghz athlon 1800+ for me ABIT KT7A - RAID (chipset is VIA KT133A /VIA 686B) kt266a, southbridge is via8233 for my system harddrive in software raid using xfs on top i don't have this, but i don't see any reason why it should cause problems Live! Value ATI 8500 64MB (x recognizes it as 8500 QL rev 0) mine is also recognized as a 8500 QL rev 0 (it's a 8500LE in fact) So your hardware seems to be fairly similar to mine. Let's see if rebuilding from cvs improves the situation for you cu Stefan Thanks for trying to help me out, Cheers Mike --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: Radeon 8500 binary snapshots now available
Michel Dänzer wrote: On Fri, 2002-07-05 at 14:55, Stefan Lange wrote: on more comment: xv seems to be broken, it only gives me a black overlay window with mplayer. are there plans to merge with gatos some time? http://www.keithp.com/~keithp/download/radeon_video.diff makes Xv work with all Radeon chips. http://www.keithp.com/~keithp/download/radeon_xv-2002-03-29-19.diff fixes the color key problems. Thanks for the links. Unfortunately Xv still doesn't work for me. But that might be because of my insufficient knowledge of how to correctly apply a patch. I did the following: -updated cvs -cd'ed to xc/programs/Xserver/hw/xfree86/drivers/ati - and then did a patch -p0 /path/to/patchfiles/radeon_video.diff (same for the other diff) is that the right way of doing it? regards Stefan --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: Radeon 8500 binary snapshots now available
[...] Yes. Keith said he successfully tested it on a 8500, maybe it depends on the other patch. OK, i had another look into my problem: I noticed that only radeon_xv-2002-03-29-19.diff applies cleanly on the r200 branch. the other patch gives me errors. So I first tried to edit the hunks that had failed manually, but the result wouldn't compile (not very surprisingly...) after that i tried to just apply the first patch (the one that applies without problems), recompiled everything, et voila: XV is working! thanks for helping me out again regards Stefan --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Ann: Radeon 8500 binary snapshots now available
Hi! I just checked out and compiled the r200-0-1-branch: glxgears: ~ 1650 fps I've just commited a small optimization that gears benefits from. It may be quite close now... its about 1720 now ;-) [...] A large part of this difference is presumably due to HyperZ - something that we can't implement in an open driver. what is hyper-z? a proprietary texture-compression function of the r200? well, as you expected, performance is exactly the same after the checkout as before rtcw (single player): working, but quite slow (performance isn't really great with firegl-drivers neither...), crashed after about 10 mins Yes, I haven't had the opportunity to do any long runs of these demos. It's a bit disappointing that they lockup, though. I'm also still experiencing crashes with q3a and wolf, after some minutes of playing. Is there anything I can do to help to track down the reason (i have to warn you though: i don't have any programming or debugging experience)? oh yeah, one other thing: in the other mail I reported that xv is broken: it works fine now for me, so I somehow messed it up before. sorry about that Keith --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parhelia vs. Radeon 8500
German Gomez Garcia wrote: Hello, I have some money to spend (finally!!!) so I'm thinking of replacing my old G400MAX for a new card, as I prefer open source, I have to choose between ATI and Matrox, and the optios (for me) are the new Parhelia 512 or the AIW Radeon 8500 DV, I'll buy whatever card works better under Linux, as far as I know somebody is working in 3D for the 8500 even TCL!!, and the Gatos project has good quality video in/out for the AIW DV. The parhelia is quite misterious, but I could wait two or three months if the drivers would be good enough. Just let me give you a short overview about the current status of the driver support: Radeon8500: 2D is supported, including working XVideo provided by the Gatos-project, 3D is supported by the closed-source FireGL-drivers by ATi. The FireGL-drivers do not support XV, so you'll have to choose wether to use 3D- or video acceleration. It's not a problem running the free/Gatos server and the FireGL server at the same time, however, so it's not too bad, just a bit uncomfortable. The development of an open-source driver for the 8500 is funded by the weather channel, and we will hopefully see working drivers by the end of the year. Parhelia: Sorry, I don't know if Matrox is planning to support the card in XF86. Currently they don't even have a driver for win9x, so it will probably be a while. But I may be completely wrong here. I'd also keep in mind the costs of both cards: You can get a 8500(LE) for less than half of what the Parhelia costs. I hope this helps a bit Stefan I would like to know if anybody from Matrox contacted developers here, well, in fact, I would like to know if I should wait for the parhelia linux drivers or go for the AIW. What do you think?? Regards, - german --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Compilation
Dieter Nützel wrote: On Monday 24 June 2002 13:09, Alexander Stohr wrote: Or you are try out the current closed source drivers for X11 and the ATI FireGL 8700/8800 - they do run on the BUILT BY ATI Radeon 8500 boards as well. The board indicates this compatibility by a PCI Subvendor ID of 0x1002 or ATI. Hello Alexander! No change to get this going on your partner boards? Even with flashed BIOS? I can get may hands on a 8500LE on top of my dual Athlon 1900+ MP/XP for testing. Hello Dieter, I've got a 3rd party 8500LE-card, and it works just fine. However: this card is only officially by FIC, but is very identical to the original ATi one. The only differences are little FIC-Stickers covering all ATi-Logos on the PCB. There's not even a FIC-string in the BIOS-info (and it's got 3.6 ns Ram *g*). I guess your mileage with other brands will vary, but flashing the BIOS might work. Thanks, Dieter [...] --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4 compiling problems
Another question. I am using the Gatos driver for hardware accelerated DVD watching. Can I use them together with the DRI Mach64 drivers? I doubt that mixing these drivers will work, because gatos uses its own drm-module (correct me if I'm wrong). You'd probably have to merge both codebases, which is not trivial. You could try a different approach to your problem: Have you tried mplayer's xvidix video out driver? It should work fine with a mach64 card, and be at least as fast as xv, if not faster (i don't know the exact numbers) Greetings, Michael --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 8500 Drivers
Peter Soetens (Kaltan) wrote: Hi, [...] Anyway about the FireGL stuff : On Sunday 02 June 2002 20:45, Garry Reisky wrote: If there are any 8500 owners out there that have been longing for 3d in linux, you can download the firegl 8800 drivers and install them . They will work . These were released a day or two ago and work on firegl and the 8500. I tested them too, but with lesser success. I have the Tyan AMD 760MP MB with two 1800+ processors. First all looks good but then... : hmm, they work all right for me (except for some freezes in quake3 and wolfenstein, when trying to change the graphics settings in the game-menu). I, however, have a single processor system, with a VIA KT266A board. [...] Off course, i know this will probably not supported, so i still hope for the open 8500 driver. yeah, me too, as the closed one doesn't offer any Xvideo extension, plus I really prefer open drivers regards Stefan cheers, Peter ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] re: RE: APT-able Debian DRI CVS packages ready fortesting.
"Marc Wilson" [EMAIL PROTECTED] 03/30 4:09 Ok, perhaps I'm really dense, but what's the advantage of using this over just using Branden's X debs? I have 3d acceleration and working DRI for both my V3 and my G450 as it stands, without adding any further software. And I can turn it on or off as I want (if I need 24 bit for something, for example). So, what's the scoop? I haven't tried the deb-packages yet, but I have tried the precompiled (cvs)-binaries from dri.sourceforge.net, and they offer me a significantly higher performance (this is important for me as I have a low-end system, and the difference between the deb-unstable packages and the sourceforge-packages means that I can now play q3a at a reasonable framerate) pokorny - Marc Wilson [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.moonkingdom.net/mwilson ___ Dri-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dri-devel
