Re: [Dri-devel] [PATCH] Wolfenstein on r128
A quick note: When you guys encounter bugs with DRI drivers on Id games, you can certainly get some help from me :-) I can look at the code and tell you how some things are done, and correct problems if any. You shouldn't expect me to become a direct contributor to DRI developement though, low level stuff is still a bit out of my league. TTimo -- Linux contractor -- Id Software Inc. On Mon, 18 Feb 2002 17:33:36 -0700 Brian Paul [EMAIL PROTECTED] wrote: Dieter Nützel wrote: Dieter Nützel wrote: Brian Paul wrote: Dieter Nützel wrote: Keith Whitwell wrote: Michel Dänzer wrote: On Son, 2002-02-17 at 18:08, Marc Dietrich wrote: Wolfenstein crashes after playing the intro at line 494 in r128_texstate.c with an assert t failed message. How do other drivers handle the same point? Latest tdfx trunk and mesa-4-0-branch hang whole system after intro. I've didn't run with debug, so can't say line xxx. I'll try with the fix. Where can I get Wolfenstein from? I thought it was an Id game but I don't see it on their website. Yes, it is an Id game. You can grep the Linux playfile or the Linux demo at Id's ftp site or many mirrors. ftp://ftp.idsoftware.com/idstuff/wolf/linux I tried the wolfspdemo-linux-1.1b.x86 version (112,4 MB). TDFX driver solved!!! I was hit but the outstanding Glide3 3DNow! texture bug (texdown seg faults)... After a recompilation of Glide3 _without_ 3DNow! enabled Wolfenstein (RTCW) runs without a hitch. Sorry for my false alarm. Cool. I have Wolfenstien running on my system with Voodoo3 and it seems to work fine. I was afraid this was going to be a really ellusive bug. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Update: R128PutImage eating too much CPU, round 2 :-]
On Tue, Feb 19, 2002 at 08:31:03AM +0100, Peter Surda wrote: If the CPU usage is really a problem, an interrupt is probably the way to go; don't know if and how the chip supports that though. Sounds good. Ok, I did some tests: - it isn't DMA-specific. It happens also with DMA disabled, so interrrupts won't help - it isn't directly either R128WaitForIdle or R128CCEWaitForIdle. Conditional usleeps in the idle loops there don't change anything. - by mistake I introduced an unconditional usleep (1) (i.e. 10ms usleep) into R128CCEWaitForIdle. Although this slowed everything down and video latency got worse, X suddenly eats about 20% less, still measurable though, about 4%. Hence, I assume the problem is caused by an idle loop in something that calls accel-Sync before the loop. I am still unable to find where exactly though. I need more ideas now :-) Mit freundlichen Gren Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023 -- Reboot America. msg02908/pgp0.pgp Description: PGP signature
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
On 2002.02.19 03:21 Daryll Strauss wrote: On Mon, Feb 18, 2002 at 06:50:36PM -0800, Gareth Hughes wrote: Sergey V. Udaltsov wrote: ... The main point of this letter: could someone please consider the possibility of periodical publishing mach64.tar.gz using the method of Gatos project: just XFree modules and drm kernel modules (I think, for libGL.* will go there too). The building of the whole tree is time- and space-consuming task, so these builds could simplify the life for ordinary but adventurous people like me. Is it wrong idea? I do not think it is very difficult to hack little shell script which makes this archive... Why limit this to the mach64 driver? We don't build binaries for anything else, and some might argue that other drivers are used more than this one and are thus more worthy of having pre-built binaries :-) If someone wants to take the role of release manager, that would be great. The job is just to keep your CVS tree up to date with all the drivers, build it all (and report any problems), and release make releases to the download page at regular intervals. It isn't a tough job. We even had people make the packaging tools a while back. All it takes is some bandwidth and cycles, which could be run in the middle of the night. So, for those of you looking to help, here's another suggestion. - |Daryll I'm willing to give it a go. Are there any scripts already done that I can base upon for automate this taks? Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach 64 success and problems
Hi, I compiled the mac64 driver following Leifs excellent mini-HOWTO. I did not find any errors after compiling in world.log. I installed XFree86 to /usr/X11R6-DRI, inserted mach64.o with insmod (I have agpgart compiled into the kernel) and started X with /usr/X11R6-DRI/bin/X which worked fine. I switched to another console and started windowmaker. I opend an xterm and tried ran glxinfo. It told me: direct rendering: no, which I think is sort of obvious because glxinfo is still linked against the old /usr/X11R6/lib/libGL.so. Quake 3 also told me there is no hardware accelerated X. I don't know too much about X11. Is is possible to have to different X11 branches on one machine or do I have to recompile all my software that use X11 (which is not possible in the case of Quake 3). I also tried to mv /usr/X11R6-DRI to /usr/X11R6 and symlink it but both did not work. Another idea probably is to compile DRI with /usr/X11R6 as a target und just move the old /usr/X11R6 to /usr/X11R6.backup and always mv the X11R6 you want to have (I still want to keep the old X11R6 because 2d acceleration is not working with the mach64 driver). Is there any other possibility to keep both trees, because I think this solution is really nasty. I think someone posted a script to exactly do this, but I searched the mailing list archive and could not find it. Thank you very much for any help, Michael ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
On 2002.02.19 10:14 Michael Thaler wrote: Hi, I compiled the mac64 driver following Leifs excellent mini-HOWTO. I did not find any errors after compiling in world.log. I installed XFree86 to /usr/X11R6-DRI, inserted mach64.o with insmod (I have agpgart compiled into the kernel) and started X with /usr/X11R6-DRI/bin/X which worked fine. I switched to another console and started windowmaker. I opend an xterm and tried ran glxinfo. It told me: direct rendering: no, which I think is sort of obvious because glxinfo is still linked against the old /usr/X11R6/lib/libGL.so. Quake 3 also told me there is no hardware accelerated X. Please check: - if /usr/lib/libGL.so.1 is pointing to /usr/X11R6-DRI/lib/libGL.so. - if xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/mach64.o was copied to /lib/modules/.../kernel/drivers/char/drm/mach64.o, and run depmod -a NOTE: you don't need to insmod mach64.o, the X does that for you. If none of this is the cause please post your /var/log/XFree86.0.log to see what is the problem. I don't know too much about X11. Is is possible to have to different X11 branches on one machine or do I have to recompile all my software that use X11 (which is not possible in the case of Quake 3). I also tried to mv /usr/X11R6-DRI to /usr/X11R6 and symlink it but both did not work. No you don't. Your programs will be using the same client libraries, except for libGL (as above). Since the X server is seperate entity you can have several an the same machine without problems. Another idea probably is to compile DRI with /usr/X11R6 as a target und just move the old /usr/X11R6 to /usr/X11R6.backup and always mv the X11R6 you want to have (I still want to keep the old X11R6 because 2d acceleration is not working with the mach64 driver). Is there any other possibility to keep both trees, because I think this solution is really nasty. I think someone posted a script to exactly do this, but I searched the mailing list archive and could not find it. You can't do that with the mach64 tree, at least not as it is configured, because it just builds part of the tree (therefore the need to lndir /usr/X11R6 to /usr/X11R6-DRI). Nevertheless you don't need it. Thank you very much for any help, Michael Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
On Tue, Feb 19, 2002 at 10:44:43AM +, José Fonseca wrote: Please check: - if /usr/lib/libGL.so.1 is pointing to /usr/X11R6-DRI/lib/libGL.so. lrwxrwxrwx1 root root 10 19. Feb 12:17 /usr/lib/libGL.so - libGL.so.1 lrwxrwxrwx1 root root 12 19. Feb 12:17 /usr/lib/libGL.so.1 - libGL.so.1.2 lrwxrwxrwx1 root root 31 19. Feb 12:11 /usr/lib/libGL.so.1.2 - /usr/X11R6-DRI/lib/libGL.so.1.2 lrwxrwxrwx1 root root 11 19. Feb 12:18 /usr/lib/libGLU.so - libGLU.so.1 lrwxrwxrwx1 root root 13 19. Feb 12:18 /usr/lib/libGLU.so.1 - libGLU.so.1.3 lrwxrwxrwx1 root root 32 19. Feb 12:12 /usr/lib/libGLU.so.1.3 - /usr/X11R6-DRI/lib/libGLU.so.1.3 - if xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/mach64.o was copied to /lib/modules/.../kernel/drivers/char/drm/mach64.o, and run depmod -a mthaler:~# lsmod Module Size Used byNot tainted mach64 71608 0 (unused) Why is the mach64 module unused? This seems strange to me I attach the glxinfo output, my XF86Config-4 and the logfile. Thanks for your help Jose, Greetings, Michael name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.2 Mesa 3.4.2 OpenGL extensions: GL_ARB_multitexture, GL_EXT_abgr, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x25 24 dc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x26 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config manual page. # (Type man XF86Config at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the ### BEGIN DEBCONF SECTION line above, and/or after the # ### END DEBCONF SECTION line below. Section Files FontPathunix/:7100# local font server # if the local font server has problems, we can fall back on these #FontPath /usr/lib/X11/fonts/TrueType FontPath/usr/lib/X11/fonts/misc/:unscaled FontPath/usr/lib/X11/fonts/100dpi/:unscaled FontPath/usr/lib/X11/fonts/75dpi/:unscaled FontPath /usr/lib/X11/fonts/misc/:unscaled FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi FontPath/usr/lib/X11/fonts/cyrillic EndSection Section Module LoadGLcore Loadbitmap Loaddbe Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadpex5 Loadrecord Loadspeedo Loadtype1 Loadvbe Loadxie EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc105 Option XkbLayout de Option XkbVariantnodeadkeys EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/gpmdata Option Protocol PS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier Generic Mouse Driver mouse Option SendCoreEventstrue Option Device/dev/input/mice Option Protocol
Re: [Dri-devel] Mach 64 success and problems
I don't have a Mach64 chipset but looked at the attached files... You seem to get out of video memory, starting X at a lower depth might help (16bpp, that is) ! From your X log: ... (WW) ATI(0): DRI static buffer allocation failed -- need at least 9216 kB video memory (II) ATI(0): Using XFree86 Acceleration Architecture (XAA) Setting up tile and stipple cache: 32 128x128 slots 10 256x256 slots (==) ATI(0): Backing store disabled (==) ATI(0): Silken mouse enabled (**) Option dpms (**) ATI(0): DPMS enabled (WW) ATI(0): Option UseFBDev is not used (II) ATI(0): Direct rendering disabled ... And that's the reason why the mach64 module is unused... Hope this helps, Rene -- R. Reucher voice: +49/621/4803-174 COMPAREX GmbH, VL40fax:+49/621/4803-141 Mannheimerstr. 105 e-mail: [EMAIL PROTECTED] D-68535 Edingen-Neckarhausen ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
On Tue, Feb 19, 2002 at 02:00:54PM +0100, R. Reucher wrote: Thank you very much! Now I get: mthaler:~# lsmod Module Size Used byNot tainted mach64 71544 1 but glxinfo still shows: mthaler:~# glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No which is really strange because quake3 runs perfect, it even runs with 1024x768, not good but I guess without DRI this would not work at all. In 640x480 it is really quite good considering the driver is not using agp or dma. glxgears gives me: mthaler:~# glxgears 710 frames in 5.0 seconds = 142.000 FPS 700 frames in 5.0 seconds = 140.000 FPS 800 frames in 5.0 seconds = 160.000 FPS thanks a lot! Michael ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
On Tuesday 19 February 2002 14:48, Michael Thaler wrote: On Tue, Feb 19, 2002 at 02:00:54PM +0100, R. Reucher wrote: Thank you very much! Now I get: mthaler:~# lsmod Module Size Used byNot tainted mach64 71544 1 but glxinfo still shows: mthaler:~# glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No Then it's still not working correctly ! Please look at your XFree86.0.log again and search for direct rendering !!! which is really strange because quake3 runs perfect, it even runs with 1024x768, not good but I guess without DRI this would not work at all. In 640x480 it is really quite good considering the driver is not using agp or dma. Hmmm, this might just be caused by the less color bits you're using now... glxgears gives me: mthaler:~# glxgears 710 frames in 5.0 seconds = 142.000 FPS 700 frames in 5.0 seconds = 140.000 FPS 800 frames in 5.0 seconds = 160.000 FPS Not sure, but I'd say that's not fast enough. But then again, I don't have a Mach64... thanks a lot! NP, but I suspect there's still a problem left... check the log ! Rene -- R. Reucher voice: +49/621/4803-174 COMPAREX GmbH, VL40fax:+49/621/4803-141 Mannheimerstr. 105 e-mail: [EMAIL PROTECTED] D-68535 Edingen-Neckarhausen It is not enough to succeed. Others must fail. -- Gore Vidal ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
On Tue, Feb 19, 2002 at 03:10:19PM +0100, R. Reucher wrote: Then it's still not working correctly ! Please look at your XFree86.0.log again and search for direct rendering !!! (II) ATI(0): [drm] created mach64 driver at busid PCI:1:0:0 (II) ATI(0): [drm] added 4096 byte SAREA at 0xc88dd000 (II) ATI(0): [drm] mapped SAREA 0xc88dd000 to 0x40017000 (II) ATI(0): [drm] framebuffer handle = 0xfd00 (II) ATI(0): [drm] added 1 reserved context for kernel (II) ATI(0): [agp] Mode 0x1f000201 [AGP 0x8086/0x7190; Card 0x1002/0x4c4d] (II) ATI(0): [agp] 8192 kB allocated with handle 0xc90e (II) ATI(0): [agp] vertex buffers handle = 0x4000 (II) ATI(0): [agp] Vertex buffers mapped at 0x409ec000 (II) ATI(0): [drm] register handle = 0xfecff000 (II) ATI(0): Visual configs initialized (II) ATI(0): Block 0 base at 0xfecff400 (II) ATI(0): Memory manager initialized to (0,0) (1024,2463) (II) ATI(0): Reserved back buffer from (0,768) to (1024,1536) (II) ATI(0): Reserved depth buffer from (0,1536) to (1024,2304) (II) ATI(0): Reserved 3265 kb for textures at offset 0x4cf800 (II) ATI(0): Using XFree86 Acceleration Architecture (XAA) Setting up tile and stipple cache: 32 128x128 slots 18 256x256 slots 6 512x512 slots (==) ATI(0): Backing store disabled (==) ATI(0): Silken mouse enabled (**) Option dpms (**) ATI(0): DPMS enabled (WW) ATI(0): Option UseFBDev is not used (II) ATI(0): X context handle = 0x0001 (II) ATI(0): [drm] installed DRM signal handler (II) ATI(0): [DRI] installation complete (II) ATI(0): [drm] Added 128 16384 byte DMA buffers (II) ATI(0): [drm] Mapped 128 DMA buffers at 0x40bec000 (II) ATI(0): Direct rendering enabled It definitely says direct rendering is enabled! Hmmm, this might just be caused by the less color bits you're using now... No, fist of all Quake3 gives you an error message if you don't have DRI enabled. It allows you to start explicitly with software rendering, but just forget it, I tried it, you cannot even play in 320x200. mthaler:~# glxgears 710 frames in 5.0 seconds = 142.000 FPS 700 frames in 5.0 seconds = 140.000 FPS 800 frames in 5.0 seconds = 160.000 FPS Not sure, but I'd say that's not fast enough. But then again, I don't have a Mach64... I think the Mach 64 is not really fast, it is quite old. I still get: mthaler:~# glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: DRI definitely works with Quake3, that is really strange... Thanks for the help! Michael ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
Hello, Most of my problems were solved when disabling the framebuffer: [...] (WW) ATI(0): Cannot shadow an accelerated frame buffer. [...] This helps both on GATOS (2d) and DRI (3d). I have an ATI RAGE XL (onboard tyan S2462) with 4MB, so things may work different on your sys. I hope this helps, Koen Kooi ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
On Tuesday 19 February 2002 15:36, Michael Thaler wrote: (II) ATI(0): Direct rendering enabled It definitely says direct rendering is enabled! Ok, then it's working correctly ! Sorry for any confusion caused by me :-)... Hmmm, this might just be caused by the less color bits you're using now... No, fist of all Quake3 gives you an error message if you don't have DRI enabled. It allows you to start explicitly with software rendering, but just forget it, I tried it, you cannot even play in 320x200. Hehe, ok. I still get: mthaler:~# glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No And THAT is strange ! But who cares... server glx vendor string: SGI server glx version string: 1.2 server glx extensions: DRI definitely works with Quake3, that is really strange... I agree :-)- Rene -- R. Reucher voice: +49/621/4803-174 COMPAREX GmbH, VL40fax:+49/621/4803-141 Mannheimerstr. 105 e-mail: [EMAIL PROTECTED] D-68535 Edingen-Neckarhausen The moon may be smaller than Earth, but it's further away. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Repeatable lockup with Radeon QD on AMD 751 chipset.
Having recently installed and got running an original Radeon QD card, I've discovered a simple and reliable way to lock the card up: I run the xscreensaver-demo version of gears with -delay 0 -fps -wireframe. I've seen the same lockup with flightgear once, with one of the fastest aircraft, and nowhere else - it doesn't happen with gears without the -wireframe option. With -wireframe, it takes at most a minute or so to lock up. This happens with one opengl program running - I haven't tried with more than one. I can run Q3A timedemos without locking up - setting com_maxfps to 130 makes no difference to this (aside from upping the average framerate). The lockup starts out being incomplete: the mouse pointer will still respond, but the windowmanager won't: windows won't redraw, none of the keyboard shortcuts respond, but the mouse pointer behaves normally. After a bit of time, or if any new program is started, or if Alt-SysRq-b is hit, it locks up hard, and needs a hardware reset to reboot. I tried sshing in, and succeeded in logging on and getting a shell, but it locked up solid immediately after that. Hitting Alt-SysRq-t shows gears in R state, in sys_ioctl(), where the call into filp-f_op-ioctl is made. Running strace on gears shows it making lots of ioctls, and then hitting a point where the ioctl() calls fail with -EBUSY. The transition point of the strace output: ioctl(4, 0x6444, 0) = 0 ioctl(4, 0x6444, 0) = 0 ioctl(4, 0x6444, 0) = 0 ioctl(4, 0x6444, 0) = 0 ioctl(4, 0x6444, 0) = 0 ioctl(4, 0x6447, 0) = 0 write(3, +\1\1\0, 4) = 4 read(3, \1\2A\6\0\0\0\0\1\0@\5\0\0\0\0\1\0\0\0\0\0\0\0\1\0\0\0\330\10\363\10, 32) = 32 ioctl(3, 0x541b, [0]) = 0 ioctl(4, 0x4008642a, 0xb304)= 0 ioctl(4, 0x40186448, 0xb324)= 0 ioctl(4, 0x4010644f, 0xbfffebc4)= 0 ioctl(4, 0xc0286429, 0xbfffeba4)= 0 ioctl(4, 0x4008642a, 0xbfffec34)= 0 ioctl(4, 0x4010644f, 0xbfffec04)= 0 ioctl(4, 0x4008642b, 0xbfffec74)= 0 ioctl(4, 0x4008642a, 0xbfffec04)= 0 ioctl(4, 0x4010644f, 0xbfffebd4)= 0 ioctl(4, 0x6444, 0) = -1 EBUSY (Device or resource busy) There was a long list of these - the lockup didn't happen at this point, but after another 900 or so failed ioctls. Loading the radeon.o module with the debug option enabled dumps a load of gunk all over my /var/log/kern.log file . . . It overwrites the file way before the point where it would have started writing, so something strange is happening there . . . I've tried looking through the code, but I can't make head nor tail of it, so I don't have the foggiest notion how to work out what's going wrong here. I'm willing to try any suggestions/patches/whatever in order to track it down. The details of my system: I'm running kernel 2.4.18-pre9. I have Xfree86 4.2 installed from CVS, and the latest DRI CVS code. I have an ASUS K7M motherboard - this has the AMD 751 northbridge. The card is a Radeon QD: lspci reports 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon QD (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 008a Flags: bus master, stepping, 66Mhz, medium devsel, latency 64, IRQ 11 Memory at d800 (32-bit, prefetchable) [size=128M] I/O ports at 9800 [size=256] Memory at efe8 (32-bit, non-prefetchable) [size=512K] Expansion ROM at efe6 [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 for the card, and 00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] AGP Bridge (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 8000-9fff Memory behind bridge: efd0-efef Prefetchable memory behind bridge: d7b0-e7bf for the AGP chipset. The motherboard's bios is out of date - an update is out there, which I was unable to apply because of a dead floppy drive. The update was a features update, rather a bugfix one (unless the docs for it were incomplete). I have a K7 550 in there, running at 550MHz. I have the mem=nopentium thing on the kernel command line. processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 1 model name : AMD-K7(tm) Processor stepping: 2 cpu MHz : 553.899 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat mmx syscall mmxext 3dnowext 3dnow bogomips: 1104.28 Finally, I've had a good
Re: [Dri-devel] [PATCH] Wolfenstein on r128
On Tue, Feb 19, 2002 at 10:01:52AM +0100, Timothee Besset wrote: A quick note: When you guys encounter bugs with DRI drivers on Id games, you can certainly get some help from me :-) Then perhaps you can answer this question for us. Do either Q3 or RtCW use the 3rd texture unit on Radeon cards under Linux? I only ask because Q3 is one of the standard tests for DRI, and support is currently being added for the 3rd texture unit. -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
On 2002.02.19 14:36 Michael Thaler wrote: On Tue, Feb 19, 2002 at 03:10:19PM +0100, R. Reucher wrote: ... (II) ATI(0): Direct rendering enabled It definitely says direct rendering is enabled! Yes. That's is definitely true. ... I still get: mthaler:~# glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: The only explanation I see is that glxinfo is not picking up the correct libGL.so. Since this issue can came back to haunt you later, please do 'ldd /usr/X11R6/bin/glxinfo' and also 'ldd /usr/X11R6/bin/glxgears' (paths may vary). DRI definitely works with Quake3, that is really strange... Thanks for the help! Michael Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
On Monday 18 February 2002 10:35 pm, Keith Whitwell wrote: The rings are in agp space. It's a bug in the security model of the i810, it's arcane, but believe me it's real. Which leaves it open to attack because the AGP space isn't covered by the protection system. Got to wonder what they were thinking with that- to come up with a nice scheme for protecting the system against rogue code submitted from userspace to leave it open like that. I guess they thought it'd be difficult to implement an exploit with that. I ought to read up more on the rings- I got the impression from the documentation that they were just out in memory and were purely DMAed from anywhere in system memory. Thank you for being patient and putting up w/me here... :-) -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
José Fonseca wrote: On 2002.02.19 14:36 Michael Thaler wrote: On Tue, Feb 19, 2002 at 03:10:19PM +0100, R. Reucher wrote: ... (II) ATI(0): Direct rendering enabled It definitely says direct rendering is enabled! Yes. That's is definitely true. ... I still get: mthaler:~# glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: The only explanation I see is that glxinfo is not picking up the correct libGL.so. Since this issue can came back to haunt you later, please do 'ldd /usr/X11R6/bin/glxinfo' and also 'ldd /usr/X11R6/bin/glxgears' (paths may vary). DRI definitely works with Quake3, that is really strange... set the LIBGL_DEBUG env var to 'verbose' and see what libGL says. Maybe libGL isn'f finding the mach64_dri.so file. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
mthaler:~# glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: Try running glxinfo with LIBGL debugging enabled (LIBGL_DEBUG=verbose glxinfo), that might help to trace the problem. Laurent Pinchart ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Wolfenstein on r128
What is the name of the extension? Since it's not implemented in the DRI, I can tell for sure that it's not used on linux, and it's likely not used on win32 either (at least for Q3, the number of extensions used was restricted to only the major ones). One thing that RTCW uses on win32/ATI though, are the truform extensions PN_TRIANGLES_*_ATI, which I'd turn on if they become available on linux. But I'd say getting TL is way more important :-) TTimo On Tue, 19 Feb 2002 07:21:43 -0800 Ian Romanick [EMAIL PROTECTED] wrote: On Tue, Feb 19, 2002 at 10:01:52AM +0100, Timothee Besset wrote: A quick note: When you guys encounter bugs with DRI drivers on Id games, you can certainly get some help from me :-) Then perhaps you can answer this question for us. Do either Q3 or RtCW use the 3rd texture unit on Radeon cards under Linux? I only ask because Q3 is one of the standard tests for DRI, and support is currently being added for the 3rd texture unit. -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
On Tue, 2002-02-19 at 15:35, Koen Kooi wrote: Most of my problems were solved when disabling the framebuffer: The framebuffer is the memory on the video card, so what exactly have you disabled? :) [...] (WW) ATI(0): Cannot shadow an accelerated frame buffer. [...] Isn't this a perfectly normal message from the atimisc driver? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Repeatable lockup with Radeon QD on AMD 751 chipset.
On Wed, Feb 20, 2002 at 02:13:17AM +1100, Simon Fowler wrote: Loading the radeon.o module with the debug option enabled dumps a load of gunk all over my /var/log/kern.log file . . . It overwrites the file way before the point where it would have started writing, so something strange is happening there . . . And it turns out that this isn't true - the lockup appears to dump a large amount of binary crap into the logfile, but the debugging info up to that point is intact. I've attatched the full log, from module load time to where the binary crap starts. Simon Fowler -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ Feb 20 01:14:25 caccini kernel: [drm] Debug messages ON Feb 20 01:14:25 caccini kernel: [drm:drm_count_cards] Feb 20 01:14:25 caccini kernel: [drm:drm_count_cards] numdevs = 1 Feb 20 01:14:25 caccini kernel: [drm:radeon_stub_register] Feb 20 01:14:25 caccini kernel: [drm:radeon_stub_register] calling inter_module_register Feb 20 01:14:25 caccini kernel: [drm] AGP 0.99 on AMD Irongate @ 0xe800 64MB Feb 20 01:14:25 caccini kernel: [drm:radeon_ctxbitmap_next] drm_ctxbitmap_next bit : 0 Feb 20 01:14:25 caccini kernel: [drm:radeon_ctxbitmap_init] drm_ctxbitmap_init : 0 Feb 20 01:14:25 caccini kernel: [drm] Initialized radeon 1.2.0 20010405 on minor 0 Feb 20 01:14:38 caccini kernel: [drm:radeon_open] open_count = 0 Feb 20 01:14:38 caccini kernel: [drm:radeon_open_helper] pid = 806, minor = 0 Feb 20 01:14:38 caccini kernel: [drm:radeon_setup] Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_flush] pid = 806, device = 0xe200, open_count = 1 Feb 20 01:14:38 caccini kernel: [drm:radeon_release] open_count = 1 Feb 20 01:14:38 caccini kernel: [drm:radeon_release] pid = 806, device = 0xe200, open_count = 1 Feb 20 01:14:38 caccini kernel: [drm:radeon_fasync] fd = -1, device = 0xe200 Feb 20 01:14:38 caccini kernel: [drm:radeon_takedown] Feb 20 01:14:38 caccini kernel: [drm:radeon_open] open_count = 0 Feb 20 01:14:38 caccini kernel: [drm:radeon_open_helper] pid = 806, minor = 0 Feb 20 01:14:38 caccini kernel: [drm:radeon_setup] Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_flush] pid = 806, device = 0xe200, open_count = 1 Feb 20 01:14:38 caccini kernel: [drm:radeon_release] open_count = 1 Feb 20 01:14:38 caccini kernel: [drm:radeon_release] pid = 806, device = 0xe200, open_count = 1 Feb 20 01:14:38 caccini kernel: [drm:radeon_fasync] fd = -1, device = 0xe200 Feb 20 01:14:38 caccini kernel: [drm:radeon_takedown] Feb 20 01:14:38 caccini kernel: [drm:radeon_open] open_count = 0 Feb 20 01:14:38 caccini kernel: [drm:radeon_open_helper] pid = 806, minor = 0 Feb 20 01:14:38 caccini kernel: [drm:radeon_setup] Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0x40086410, nr=0x10, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_addmap] offset = 0x, size = 0x2000, type = 2 Feb 20 01:14:38 caccini kernel: [drm:radeon_addmap] 8192 13 e0a5e000 Feb 20 01:14:38 caccini kernel: [drm:radeon_mmap] start = 0x40016000, end = 0x40018000, offset = 0xe0a5e000 Feb 20 01:14:38 caccini kernel: [drm:radeon_vm_open] 0x40016000,0x2000 Feb 20 01:14:38 caccini kernel: [drm:radeon_vm_shm_nopage] shm_nopage 0x40016000 Feb 20 01:14:38 caccini kernel: [drm:radeon_vm_shm_nopage] shm_nopage 0x40017000 Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_addmap] offset = 0xd800, size = 0x0200, type = 0 Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0xc0086426, nr=0x26, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0xc0086426, nr=0x26, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=1 Feb 20 01:14:38 caccini kernel: [drm:radeon_ioctl] pid=806,
Re: [Dri-devel] Pseudo DMA?
Frank C. Earl wrote: On Monday 18 February 2002 10:35 pm, Keith Whitwell wrote: The rings are in agp space. It's a bug in the security model of the i810, it's arcane, but believe me it's real. Which leaves it open to attack because the AGP space isn't covered by the protection system. Got to wonder what they were thinking with that- to come up with a nice scheme for protecting the system against rogue code submitted from userspace to leave it open like that. I guess they thought it'd be difficult to implement an exploit with that. I ought to read up more on the rings- I got the impression from the documentation that they were just out in memory and were purely DMAed from anywhere in system memory. I'm pretty sure it was an oversight. I don't think I can talk about why I think that, though... Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
On Tue, 2002-02-19 at 16:40, Michael Thaler wrote: On Tue, Feb 19, 2002 at 03:13:39PM +, José Fonseca wrote: The only explanation I see is that glxinfo is not picking up the correct libGL.so. Since this issue can came back to haunt you later, please do 'ldd /usr/X11R6/bin/glxinfo' and also 'ldd /usr/X11R6/bin/glxgears' (paths may vary). You are right: mthaler:~# ldd /usr/X11R6/bin/glxinfo libGL.so.1 = /usr/X11R6/lib/libGL.so.1 (0x4009c000) ... where quake3 probably uses the libGL from /usr/lib/ mthaler:~# ls -l /usr/lib/libGL* lrwxrwxrwx1 root root 10 19. Feb 12:17 /usr/lib/libGL.so - libGL.so.1 lrwxrwxrwx1 root root 12 19. Feb 12:17 /usr/lib/libGL.so.1 - libGL.so.1.2 lrwxrwxrwx1 root root 31 19. Feb 12:11 /usr/lib/libGL.so.1.2 - /usr/X11R6-DRI/lib/libGL.so.1.2 ... Do you think it is a good idea to copy the libGL over to /usr/X11R6/lib? Thanks a lot, Michael No, there's no need. You probably just have to change the order on which /usr/lib/ and /usr/X11R6/lib/ directories appear on /etc/ld.so.conf and run '/sbin/ldconfig' Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Wolfenstein on r128
On Tue, Feb 19, 2002 at 04:42:02PM +0100, Timothee Besset wrote: What is the name of the extension? Since it's not implemented in the DRI, I can tell for sure that it's not used on linux, and it's likely not used on win32 either (at least for Q3, the number of extensions used was restricted to only the major ones). It's just the regular old ARB multitexture extension. That particular extension supports (somebody correct me if I'm wrong) between 2 and 8 texture units. All cards except the original Radeon only have 2 texture units. The Radeon has 3. Back on 17-May-2000 John said in a .plan that games that do a significant number of rendering passes on the entire world may go back in ATI's favor if they can use the third texture unit, but I doubt it will be all that common. However, he never said if it would be common in id games. :) -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
On Tue, 2002-02-19 at 18:28, Malte Cornils wrote: Jose Fonseca wrote: mthaler:~# ldd /usr/X11R6/bin/glxinfo libGL.so.1 = /usr/X11R6/lib/libGL.so.1 (0x4009c000) where quake3 probably uses the libGL from /usr/lib/ lrwxrwxrwx1 root root 31 19. Feb 12:11 /usr/lib/libGL.so.1.2 - /usr/X11R6-DRI/lib/libGL.so.1.2 No, there's no need. You probably just have to change the order on which /usr/lib/ and /usr/X11R6/lib/ directories appear on /etc/ld.so.conf and run '/sbin/ldconfig' Unfortunately, /usr/lib is *always* the first directory to get parsed no matter what /etc/ld.so.conf says - due to security reasons (man ldconfig and experiment!) ... Yours Malte #8-) The man page indeed mentions that, but how do you explain what is happening!? I was really suggesting to put /usr/lib before /usr/X11R6/lib because the libGL we are interest in is already symlink'd in /usr/lib... Perhaps it's picking /usr/X11R6/lib/libGL because it's in the same dir as the executables. Michael, please try to copy the glxinfo glxgears binaries to other place and run them from there. Regards, Jose' Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Unreal [was: Mach 64 success and problems]
On Tue, Feb 19, 2002 at 05:17:16PM +, Jose Fonseca wrote: No, there's no need. You probably just have to change the order on which /usr/lib/ and /usr/X11R6/lib/ directories appear on /etc/ld.so.conf and run '/sbin/ldconfig' I just symlinked the libGL and the libGLU in /usr/X11R6/lib to /usr/X11R-DRI/lib and everything works fine. Thank you for all your efforts to get the Mach64 driver working. I tried Quake3 and Unreal with Windows2000 on my laptop but it did not work at all. Quake3 crashed when starting it and Unreal was so slow you could not play at all. I think the Win driver of my notebook just don't have any OpenGL acceleration. Quake 3 really works fine for me (I am not a big computer player, but it is nice to get it working anyway, just for the fun of it!:))) Unfortunately Unreal is not working. It is loading and running just fine, the menues are displayed correctly but the intro and the game graphics are just rubbish. Has anyone seen that before? I installe UT from a windows CD with the newest package (I think it is called ut-install-436.sh from the loki page). Has anyone got UT working with Mach64? Anyway, if AGP and DMA is working with the driver, it is probably a lot faster und one maybe can even play Quake3 with 800x600. So thank you all again for your great work, Michael ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
On Tue, Feb 19, 2002 at 07:28:54PM +0100, Malte Cornils wrote: Jose Fonseca wrote: No, there's no need. You probably just have to change the order on which /usr/lib/ and /usr/X11R6/lib/ directories appear on /etc/ld.so.conf and run '/sbin/ldconfig' Unfortunately, /usr/lib is *always* the first directory to get parsed no matter what /etc/ld.so.conf says - due to security reasons (man ldconfig and experiment!) The only halfway easy (but ugly) solution was indeed to copy/symlink the DRI-enabled libGL to /usr/lib. Any hints how to do it in a better way? How about the obvious? Don't put libGL (and friends) in /usr/lib. Always put them in /usr/X11*/lib. If you have some other libGL (standalone Mesa, perhaps), but it in /usr/local/lib. -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
Ian Romanick wrote: Any hints how to do it in a better way? How about the obvious? Don't put libGL (and friends) in /usr/lib. Always put them in /usr/X11*/lib. If you have some other libGL (standalone Mesa, perhaps), but it in /usr/local/lib. Yes, I might do that if it wouldn't greatly confuse my distro's packaging scheme. But alas, it does. In the meantime, copying the correct libGL works better. Thanks for the suggestion, though! -Malte #8-) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
Leif Delgass wrote: I thought this was done by make install, I have: % ls -l /usr/lib/libGL* lrwxrwxrwx1 root root 27 Feb 18 19:34 /usr/lib/libGL.so - /usr/X11R6-DRI/lib/libGL.so lrwxrwxrwx1 root root 29 Feb 18 19:34 /usr/lib/libGL.so.1 - /usr/X11R6-DRI/lib/libGL.so.1 Hmm, my system shows: mcornils@wh36-b407:/usr/lib$ ls -la libGL.so* lrwxrwxrwx1 root root 12 21. Jan 21:37 libGL.so.1 - libGL.so.1.2 lrwxrwxrwx1 root root 25 21. Jan 21:37 libGL.so.1.2 - ../X11R6/lib/libGL.so.1.2 which is the libGL from the old Xfree (I've just installed the mach64 branch). At the moment, I'm using LD_LIBRARY_PATH=/usr/X11R6-DRI/lib:$LD_LIBRARY_PATH, maybe that turns out to be a good idea. Yours Malte #8-) PS: No need to Cc: me, I'm lurking anyway :-) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
Hi all Once again, I managed to came through the waters and fires of the updating and building process. Again, got DRM working with my humble Mobility (at least with glxgears/tunnel). There are 2 minor questions: 1. After all these discussions in IRC, I realized that fog in Mach64 is not ready yet. Is it? So the fact I cannot see fog in the tunnel - it is OK for a moment, isn't it? 2. For some reason, X server gets signal 11 after closing any GL program. Is it registered bug? Can I help with debugging (with my XFree.0.log/dmesg)? Anyway, Jos's effort for packaging is still in very high demand among me, my system, and openuniverse:) Hope others are interested too. Thanks for support to this idea. Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
Malte Cornils wrote: Leif Delgass wrote: I thought this was done by make install, I have: % ls -l /usr/lib/libGL* lrwxrwxrwx1 root root 27 Feb 18 19:34 /usr/lib/libGL.so - /usr/X11R6-DRI/lib/libGL.so lrwxrwxrwx1 root root 29 Feb 18 19:34 /usr/lib/libGL.so.1 - /usr/X11R6-DRI/lib/libGL.so.1 Hmm, my system shows: mcornils@wh36-b407:/usr/lib$ ls -la libGL.so* lrwxrwxrwx1 root root 12 21. Jan 21:37 libGL.so.1 - libGL.so.1.2 lrwxrwxrwx1 root root 25 21. Jan 21:37 libGL.so.1.2 - ../X11R6/lib/libGL.so.1.2 OK, Allen Akin told you what the LSB standard is: libGL* belongs into /usr/lib. /usr/lib l libGL* libglut* lrwxrwxrwx1 root root 23 Feb 17 01:50 libGL.so - /usr/X11R6/lib/libGL.so lrwxrwxrwx1 root root 25 Feb 17 01:50 libGL.so.1 - /usr/X11R6/lib/libGL.so.1 lrwxrwxrwx1 root root 24 Feb 6 03:12 libGLU.so - /usr/X11R6/lib/libGLU.so lrwxrwxrwx1 root root 26 Feb 6 03:12 libGLU.so.1 - /usr/X11R6/lib/libGLU.so.1 lrwxrwxrwx1 root root 25 Feb 6 02:38 libglut.so - /usr/X11R6/lib/libglut.so lrwxrwxrwx1 root root 27 Feb 6 02:38 libglut.so.3 - /usr/X11R6/lib/libglut.so.3 To be warned: Some older apps need libMesaGL*. But I do not need that...;-) X11R6/lib l libGL* libglut* -rw-r--r--1 root root 559630 Jan 21 18:56 libGL.a lrwxrwxrwx1 root root 12 Feb 17 01:50 libGL.so - libGL.so.1.2 lrwxrwxrwx1 root root 12 Feb 17 01:50 libGL.so.1 - libGL.so.1.2 -rwxr-xr-x1 root root 509595 Feb 17 01:50 libGL.so.1.2 -rw-r--r--1 root root 680916 Jan 21 18:56 libGLU.a lrwxrwxrwx1 root root 13 Feb 17 01:50 libGLU.so - libGLU.so.1.3 lrwxrwxrwx1 root root 13 Feb 17 01:50 libGLU.so.1 - libGLU.so.1.3 -rwxr-xr-x1 root root 711754 Feb 17 01:50 libGLU.so.1.3 -rw-r--r--1 root root26344 Feb 17 01:50 libGLw.a lrwxrwxrwx1 root root 16 Feb 17 01:49 libglut.so - libglut.so.3.7.0 lrwxrwxrwx1 root root 16 Feb 17 01:49 libglut.so.3 - libglut.so.3.7.0 -rwxr-xr-x1 root root 291916 Feb 18 17:16 libglut.so.3.7.0 X11R6/lib l *Mesa* -rw-r--r--1 root root 1718066 Feb 17 01:50 libOSMesa.a lrwxrwxrwx1 root root 16 Feb 17 01:50 libOSMesa.so - libOSMesa.so.4.0 lrwxrwxrwx1 root root 16 Feb 17 01:50 libOSMesa.so.4 - libOSMesa.so.4.0 -rwxr-xr-x1 root root 1595079 Feb 17 01:50 libOSMesa.so.4.0 which is the libGL from the old Xfree (I've just installed the mach64 branch). At the moment, I'm using LD_LIBRARY_PATH=/usr/X11R6-DRI/lib:$LD_LIBRARY_PATH, maybe that turns out to be a good idea. That's not stupid...;-) And please send cat /proc/dri/0/* Cheers, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
That's because tunnel tries to use alpha blending _and_ fog, which isn't possible on mach64 (we're looking into a workaround though). If you OK. For a moment, I just will remember this fact. 2. For some reason, X server gets signal 11 after closing any GL program. Is it registered bug? Can I help with debugging (with my XFree.0.log/dmesg)? Hmmm, I haven't seen that. Post the logs and we can take a look. OK. With my pleasure. Actually, almost all the stuff in this file is from the initialization. Till the line Open APM successful. Actions: 1. In vt1, I do /usr/X11R6-DRI/bin/X 2. In vt2, I do DISPLAY=:0.0 glxinfo.. 3. Switch to vt4. The whole system crashes but glxinfo returns some sensible data. If I use glxgears instead, it runs till I stop it (by Ctl-C in vt2) and X terminates with the same signal 11. Does it have something to do with vt management? Cheers, Sergey This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.1.99.1 (DRI mach64 branch) / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 20 August 2001 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/FAQ) Build Operating System: Linux 2.4.17-0.12 i686 [ELF] Module Loader present (==) Log file: /var/log/XFree86.0.log, Time: Tue Feb 19 23:39:31 2002 (==) Using config file: /etc/X11/XF86Config Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) ServerLayout Simple Layout (**) |--Screen Screen 1 (0) (**) | |--Monitor gw (**) | |--Device gw (**) |--Input Device Mouse1 (**) |--Input Device USBMouse (**) |--Input Device Keyboard1 (**) Option AutoRepeat 500 30 (**) Option XkbKeymap en_ru_de (**) XKB: keymap: en_ru_de (overrides other XKB settings) (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7000 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (**) ModulePath set to /usr/X11R6-DRI/lib/modules,/usr/X11R6-DRI/lib/modules/multimedia (--) using VT number 7 (II) Open APM successful (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-DRI/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.1.99.1, 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-DRI/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.1.99.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,7190 card 107b,9300 rev 03 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,7191 card , rev 03 class 06,04,00 hdr 01 (II) PCI: 00:07:0: chip 8086,7110 card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:07:1: chip 8086,7111 card , rev 01 class 01,01,80 hdr 00 (II) PCI: 00:07:2: chip 8086,7112 card , rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:07:3: chip 8086,7113 card , rev 03 class 06,80,00 hdr 00 (II) PCI: 00:08:0: chip 125d,1978 card 107b,9300 rev 10 class 04,01,00 hdr 00 (II) PCI: 00:0b:0: chip 11c1,0448 card 1668,2000 rev 01 class 07,80,00 hdr 00 (II) PCI: 00:0c:0: chip 104c,ac40 card 4000, rev 00 class 06,07,00 hdr 82 (II) PCI: 00:0c:1: chip 104c,ac40 card 4800, rev 00 class 06,07,00 hdr 82 (II) PCI: 00:0c:2: chip 104c,8011 card 107b,9300 rev 00 class 0c,00,10 hdr 80 (II) PCI: 01:00:0: chip 1002,4c4d card 107b,9300 rev 64 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) LoadModule: scanpci (II) Loading /usr/X11R6-DRI/lib/modules/libscanpci.a (II) Module scanpci: vendor=The XFree86 Project compiled for 4.1.99.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) UnloadModule: scanpci (II) Unloading /usr/X11R6-DRI/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable
Re: [Dri-devel] [PATCH] Wolfenstein on r128
Ian Romanick wrote: On Tue, Feb 19, 2002 at 04:42:02PM +0100, Timothee Besset wrote: What is the name of the extension? Since it's not implemented in the DRI, I can tell for sure that it's not used on linux, and it's likely not used on win32 either (at least for Q3, the number of extensions used was restricted to only the major ones). It's just the regular old ARB multitexture extension. That particular extension supports (somebody correct me if I'm wrong) between 2 and 8 texture units. The spec supports up to 32 texture units. Mesa allows up to 8. All cards except the original Radeon only have 2 texture units. The Radeon has 3. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] UT source build instructions
I've put the UT (partial) source, the specific version of openal and build instructions at http://mefriss1.swan.ac.uk/~jfonseca/dri/ut/ . This is just a tarball of what I had on my hardriver and it hasn't been tested for a long time so please be patient if you encounter problems. Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] TCL
Just a note that I've committed the bulk of a functional tcl radeon driver to the new 'tcl-0-0-branch'. This is basically my code as of about a 10 days ago, which exercises most of the tl hardware but doesn't have any cool optimizations. Since then I've been working on cool optimizations, but they're not ready yet. I'm now running a compile on what I committed there will probably be a few more commits before it's all up running. I'll post when I think it's in a reasonable state. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
Michael wrote: I don't see your problem? I'm using debian unstable. Adding /usr/foo/bar/ to /etc/ld.so.conf and running /sbin/ldconfig works just fine (as Jose described) see man 8 ld.so, it searches LD_LIBRARY_PATH, /etc/ld.so.cache then /usr/lib and /lib. You're right. It was a recent change in Debian's libc6 package (which contains ldconfig) - see changelog.Debian for 2.2.4-5. At least for Debian unstable, I'll gladly retract my first statement. I should have rechecked before making that claim based on my memories from pre-2.2.4-5-days :-) (anyway, I'm also using a testing/unstable hybrid, and libc6 was pinned to testing - so I just got the changed libc6 a few days ago when it entered testing) Well, great. I'm sorry for all that list traffic I caused :-) Yours Malte #8-) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 success and problems
On 2002.02.19 19:35 Michael Thaler wrote: On Tue, Feb 19, 2002 at 07:02:47PM +, Jose Fonseca wrote: Michael, please try to copy the glxinfo glxgears binaries to other place and run them from there. Jose, I copied glxinfo and glxgears from /usr/X11R6 to /root and tried it with /root/glxinfo and /root/glxgears and it still uses the libGL from /usr/X11R6/lib and not the one from /usr/lib. Could it have something todo that I tried it as root? This really seems strange. When I delete the libGL from /usr/X11R6/lib it uses the correct one. Greeting, Michael No, running as root should have no difference whatsoever. Surely the problem is that /usr/X11R6/lib/libGL is being picked before /usr/lib/libGL. Now to know why you need to make some further investigations on the ldconfig and ld.so manpages and check with your system configuration. I'm sorry that can't help you more, but at least you know what the problem is and how to circunvent it for the time being, allowing you to fully enjoy the (yet rather limited) capabilities of the mach64 DRI driver. Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI binary snapshots enquires
José Fonseca wrote: I've been trying to figure out what is needed for releasing DRI binary snapshots. There are two different trees with different particularities that I'm interested for now: the trunk and the mach64-0-0-2-branch. Common: In both cases there is the need for the sources of the DRM to be built on each particular user machine/kernel combination. For these I plan to release a tarball with the sources from xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/ as Alan made in http://www.xfree86.org/~alanh/ . Trunk: For the drivers at the trunk I'll assume that the user will have XFree 4.2.0 so it will only be necessary to pack: - the DDX driver (/usr/X11R6/lib/modules/drivers/*_drv.o) - the Mesa driver (/usr/X11R6/lib/modules/dri/*_dri.so) and also: - the libGL (/usr/X11R6/lib/libGL.so) Is this sufficient? I belive so. In some respects it is a function of how divergent the XFree on peoples machines is from what's in DRI CVS. DRI's basically fucked up backwards compatibility on every front until quite recently - we now have backwards compatibility for kernel modules. But there are other interfaces the 3d driver deals with, specifically the DRI extension protocol to the X server. Thankfully this hasn't changed in a long time, and if it ever does, we know now to do it in a backwards-compatible way. My guess is this is going to be sufficient then for most if not all cases. Have you looked at Alan H's tools for sanity-checking DRI installs? I've always thought that these might be useful when trying to write an installer for DRI binary distributions. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI binary snapshots enquires
On 2002.02.20 02:07 Keith Whitwell wrote: José Fonseca wrote: ... Trunk: For the drivers at the trunk I'll assume that the user will have XFree 4.2.0 so it will only be necessary to pack: - the DDX driver (/usr/X11R6/lib/modules/drivers/*_drv.o) - the Mesa driver (/usr/X11R6/lib/modules/dri/*_dri.so) and also: - the libGL (/usr/X11R6/lib/libGL.so) Is this sufficient? I belive so. In some respects it is a function of how divergent the XFree on peoples machines is from what's in DRI CVS. DRI's basically fucked up backwards compatibility on every front until quite recently - we now have backwards compatibility for kernel modules. But there are other interfaces the 3d driver deals with, specifically the DRI extension protocol to the X server. Thankfully this hasn't changed in a long time, and if it ever does, we know now to do it in a backwards-compatible way. My guess is this is going to be sufficient then for most if not all cases. Have you looked at Alan H's tools for sanity-checking DRI installs? I've always thought that these might be useful when trying to write an installer for DRI binary distributions. Keith Daryll mentioned them and said he would try to contact Alan. I don't have those scripts. Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
On 19 Feb 2002, Sergey V. Udaltsov wrote: That's because tunnel tries to use alpha blending _and_ fog, which isn't possible on mach64 (we're looking into a workaround though). If you OK. For a moment, I just will remember this fact. 2. For some reason, X server gets signal 11 after closing any GL program. Is it registered bug? Can I help with debugging (with my XFree.0.log/dmesg)? Hmmm, I haven't seen that. Post the logs and we can take a look. OK. With my pleasure. Actually, almost all the stuff in this file is from the initialization. Till the line Open APM successful. Actions: 1. In vt1, I do /usr/X11R6-DRI/bin/X 2. In vt2, I do DISPLAY=:0.0 glxinfo.. 3. Switch to vt4. The whole system crashes but glxinfo returns some sensible data. If I use glxgears instead, it runs till I stop it (by Ctl-C in vt2) and X terminates with the same signal 11. Does it have something to do with vt management? Yes, I think so. There are still locking issues to resolve between the Mesa driver, drm and the DDX driver. Switching vts when an GL app is running will most likely lock the card at this point. You should be able to run glxinfo and glxgears from an xterm without a problem. Does X crash if you run glxgears from an xterm? btw, your Xlog seems to end at the message about virtual resolutions being limited due to ... Is that really the end? (maybe I'm having problems with the charset). -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] TCL
On Wed, Feb 20, 2002 at 01:28:38AM +, Keith Whitwell wrote: Just a note that I've committed the bulk of a functional tcl radeon driver to the new 'tcl-0-0-branch'. This is basically my code as of about a 10 days ago, which exercises most of the tl hardware but doesn't have any cool optimizations. Since then I've been working on cool optimizations, but they're not ready yet. Magic :o)) -- Michael. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI binary snapshots enquires
Have you looked at Alan H's tools for sanity-checking DRI installs? I've always thought that these might be useful when trying to write an installer for DRI binary distributions. Keith Daryll mentioned them and said he would try to contact Alan. I don't have those scripts. I saw them recently somewhere - maybe on the dri website. I'm not sure where. Alan? Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] TCL tentatively ready for adventurous testers developers...
Michael wrote: On Wed, Feb 20, 2002 at 01:28:38AM +, Keith Whitwell wrote: Just a note that I've committed the bulk of a functional tcl radeon driver to the new 'tcl-0-0-branch'. This is basically my code as of about a 10 days ago, which exercises most of the tl hardware but doesn't have any cool optimizations. Since then I've been working on cool optimizations, but they're not ready yet. Magic :o)) OK. Things seem to be more or less working now. Over the next week or so I'll be finishing and checking in code for the following: - Array (rather than vertex) based dma of vertex data. This will probably help q3 performance. - Fast code for immediate (begin/vertex/end) mode rendering. Until then, people who are interested should feel free to check the code out and have a play. I don't expect it to be too robust yet, but bug reports are welcome. Anybody doing development on the Radeon (hi Michael, Ian, others) should probably work off this codebase as it is somewhat divergent from what's on the trunk in terms of the way state is managed. I'd very much hope to get this stabilized and merged sooner rather than later. A big thanks to ATI for allowing us to release this code and to Tungsten Graphics for having the vision to persue it. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
