[Dri-devel] Debian packages of upcoming xfree86 4.3 with DRI?
Hello! Does someone have up to date Debian packages for testing the DRI of upcoming xfree 4.3 ? -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- 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] Debian packages of upcoming xfree86 4.3 with DRI?
On Sun, 2003-01-26 at 15:10, Pasi Kärkkäinen wrote: Does someone have up to date Debian packages for testing the DRI of upcoming xfree 4.3 ? http://penguinppc.org/~daniels/README -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: 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] Debian packages of upcoming xfree86 4.3 with DRI?
On Sun, Jan 26, 2003 at 04:06:26PM +0100, Michel Dänzer wrote: On Sun, 2003-01-26 at 15:10, Pasi Kärkkäinen wrote: Does someone have up to date Debian packages for testing the DRI of upcoming xfree 4.3 ? http://penguinppc.org/~daniels/README Thanks! Seems to be upgraded a couple of days ago.. nice. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- 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] DRI-CVS pseudo-lockups on radeon.o (Radeon VE/7000)
Hello, I could reproduce your X lockups with my Radeon 7500 by disabling TCL (RADEON_TCL_FORCE_DISABLE=1) which is as close as I can get to your Radeon VE. I don't use the dri_resume patch. From your telling that it helped to kill the offending GL app it sounds like the GL app gets stuck somewhere while holding the lock. It would be helpful to know where exactly that is. Unfortunately I don't have a second system at hand to log in remotely from. Could you reproduce a lockup with a GL app running in a remote debugger session. When the system is locked up you press Ctrl+C in the debugger, get backtrace with the bt command and send it to the list. About the flickering when running endgame on the root window, I could reproduce that too, even with TCL enabled. It looks to me like it is using a single buffered visual in that case. Curiously this doesn't happen when xscreensaver runs endgame on the root window. Felix On Fri, 24 Jan 2003 23:28:52 + [EMAIL PROTECTED] wrote: Hello. I've been having some troubles with dri-cvs for some time when running GL apps (especially the GL hacks that come with JWZs xscreensaver). In particular, I've noticed problems when running endgame and menger on the root and in windows and then running other windows over them or moving the GL apps window around. Occasionally, my X session locks up completely, and I can only move the mouse around, X's three-finger-salute doesn't work. What I have been able to do when this occurs (other than a hard reset) is to log in over the network and kill the offending GL app. Then, my X session is usable again. I'm currently using: $ X -version snip XFree86 Version 4.2.99.2 (DRI trunk) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 21 October 2002 snip Build Operating System: Linux 2.4.18 i686 [ELF] I updated my dri-cvs tree on the evening of Jan24, 2003 and compiled/installed it (and then the kernel modules). My video card is a Radeon VE (what is now called a Radeon 7000), I'm using it on the VGA head (as opposed to the DVI) on an ASUS CUBX-E at AGP 2, and I've also applied Charl Botha's dri_resume patch http://cpbotha.net/files/dri_resume/xfree86-dri-resume-v6.patch and I have suspended and resumed several times since the last boot. I have also, however, restarted X since the last resume. I'm using the screenhacks from v 4.06 of xscreensaver http://www.jwz.org/xscreensaver/xscreensaver-4.06.tar.gz. *** UNRELATED (I HOPE) *** In an unrelated note, when I play these hacks on the root window, they flicker a lot, unlike the non-GL, 2D hacks. ** If anyone's interested in this problem and would like me to provide any more information or test some patches, let me know. Thanks. Andy [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- 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] the greatest steak knives ever
Title: Knive Special Offer Professional Steak Knife BLOWOUT ! They slice right through even the toughest of meat with ease! Don't be fooled by imitations that you might see in your local store, these knives are only sold directly to the major steak houses like: * Outback Steakhouse * Lone Star Steak House * Ruth's Chris Steakhouse * Morton's Steakhouse CLICK Here Now These are not available to the general public in any store...This is the REAL-DEAL! We bought them straight from the manufacturer at a special wholesale price, and are only offering them directly through this ONE TIME INTERNET OFFER. AS LOW AS $12.50 per set of four ! ...to be removed click here --- 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] DRI-CVS pseudo-lockups on radeon.o (Radeon VE/7000)
I could reproduce your X lockups with my Radeon 7500 by disabling TCL (RADEON_TCL_FORCE_DISABLE=1) which is as close as I can get to your Radeon VE. I don't use the dri_resume patch. From your telling that it helped to kill the offending GL app it sounds like the GL app gets stuck somewhere while holding the lock. It would be helpful to know where exactly that is. Unfortunately I don't have a second system at hand to log in remotely from. Could you reproduce a lockup with a GL app running in a remote debugger session. When the system is locked up you press Ctrl+C in the debugger, get backtrace with the bt command and send it to the list. I tried to do this from a remote machine and locally, and both times, I get errors like: ** $ gdb GNU gdb 5.0 Copyright 2000 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-slackware-linux. (gdb) exec-file /usr/local/lib/xscreensaver/endgame (gdb) set args -display :0 (gdb) run Starting program: /usr/local/lib/xscreensaver/endgame -display :0 warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. warning: shared library handler failed to enable breakpoint Program received signal SIGFPE, Arithmetic exception. 0x404fc600 in ?? () (gdb) quit The program is running. Exit anyway? (y or n) y $ ** A window is created for the hack to run, but nothing ever appears. It appears to me that I need to compile endgame (and/or other GL hacks) with debugging information. I don't know how to do this, though. If you could direct me to some information about how I would go about it, I'd much appreciate it. About the flickering when running endgame on the root window, I could reproduce that too, even with TCL enabled. It looks to me like it is using a single buffered visual in that case. Curiously this doesn't happen when xscreensaver runs endgame on the root window. I was reading a document later about graphics coding and it mentioned that erasing the image you wanted to move, and then redrawing it would produce flicker and the solution to this was double-buffering and it reminded me of the flickering I see when running the GL hacks. I tried, and when having xscreensaver run the hacks in the root window, I get flickering. Curiouser and curiouser. Thanks. -Andy --- 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] DRI-CVS pseudo-lockups on radeon.o (Radeon VE/7000)
On Sun, Jan 26, 2003 at 03:37:03PM +, [EMAIL PROTECTED] wrote: Program received signal SIGFPE, Arithmetic exception. 0x404fc600 in ?? () (gdb) quit You need to continue here. OpenGL library is trying to determine SSE extension availability. arkadi. --- 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] DRI-CVS pseudo-lockups on radeon.o (Radeon VE/7000)
You need to continue here. OpenGL library is trying to determine SSE extension availability. You could have been a bit more explicit, like: At this point, type continue. But, I figured that out, anyway. Here's what I got from a bt: #0 0x4035a1b4 in ?? () #1 0x40503b07 in ?? () #2 0x405021de in ?? () #3 0x4050193e in ?? () #4 0x40501bdc in ?? () #5 0x40501c4a in ?? () #6 0x405147ce in ?? () #7 0x40503a7d in ?? () #8 0x40503c15 in ?? () #9 0x405021de in ?? () #10 0x4050193e in ?? () #11 0x40501bdc in ?? () #12 0x40501c4a in ?? () #13 0x405147ce in ?? () #14 0x40514c40 in ?? () #15 0x405158c5 in ?? () #16 0x40516922 in ?? () #17 0x404b5c97 in ?? () #18 0x4050e1b6 in ?? () #19 0x404b445b in ?? () #20 0x404ae65c in ?? () #21 0x403ecd9e in ?? () #22 0x403eeed6 in ?? () #23 0x804a56f in ?? () #24 0x804ac5b in ?? () #25 0x804af80 in ?? () #26 0x804b426 in ?? () #27 0x8053379 in ?? () #28 0x804a3c3 in ?? () #29 0x8051cb0 in ?? () #30 0x402cc577 in ?? () If that's not what is needed (it doesn't look helpful to me), let me know. I'm really more of an almost-poweruser, and less a coder. Thanks. -Andy --- 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] DRI-CVS pseudo-lockups on radeon.o (Radeon VE/7000)
On Sun, 26 Jan 2003 15:37:03 + [EMAIL PROTECTED] wrote: Could you reproduce a lockup with a GL app running in a remote debugger session. When the system is locked up you press Ctrl+C in the debugger, get backtrace with the bt command and send it to the list. I tried to do this from a remote machine and locally, and both times, I get errors like: ** $ gdb GNU gdb 5.0 Copyright 2000 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-slackware-linux. (gdb) exec-file /usr/local/lib/xscreensaver/endgame (gdb) set args -display :0 (gdb) run Starting program: /usr/local/lib/xscreensaver/endgame -display :0 warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. warning: shared library handler failed to enable breakpoint I've never seen this. Somehow gdb and ld.so don't seem to play together as they should. I'm afraid this way you won't get a meaningful backtrace of the radeon driver. Program received signal SIGFPE, Arithmetic exception. 0x404fc600 in ?? () (gdb) quit As Arkadi wrote this is normal, just continue. The program is running. Exit anyway? (y or n) y $ ** A window is created for the hack to run, but nothing ever appears. It appears to me that I need to compile endgame (and/or other GL hacks) with debugging information. I don't know how to do this, though. If you could direct me to some information about how I would go about it, I'd much appreciate it. This may not even help. The radeon driver is always loaded dynamically. As the error message above indicates this means that you won't be able to debug it. I don't think compiling xscreensaver yourself with debug info will help. About the flickering when running endgame on the root window, I could reproduce that too, even with TCL enabled. It looks to me like it is using a single buffered visual in that case. Curiously this doesn't happen when xscreensaver runs endgame on the root window. I was reading a document later about graphics coding and it mentioned that erasing the image you wanted to move, and then redrawing it would produce flicker and the solution to this was double-buffering and it reminded me of the flickering I see when running the GL hacks. I tried, and when having xscreensaver run the hacks in the root window, I get flickering. Curiouser and curiouser. Allright, when I turn off TCL it flickers even if xscreensaver runs it. I'll look into this one. Thanks. -Andy Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- 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] 64-bit kernel, 32-bit user. Possible? Painful?
Hi, On Fri, 24 Jan 2003, Jens Owen wrote: Keep in mind that the TDFX driver was ported to IA-64 many moons ago. I know Don Dugger had 32 bit applications (running in a 32 bit subsystem, w/ a 32 bit client side driver) direct rendering to the tdfx display controlled by a 64 bit server running on a 64 bit kernel. Cool, sounds like he has done good work for the TDFX driver, I'm new to dri, but sounds like a thing to look for example code. If I recall there was some kind of 32bit to 64bit thunking layer for kernel calls. Yes, all 64-bit Linux I know has an 32-bit compatibility layer in the kernel, you can find the files using find /usr/src/linux/arch|grep 32. For x86_64, most of it is in arch/x86_64/ia32/*.c The compatibility layer has different levels it needs to cover: the 32-bit user system entry and leave, mapping of 32-bit syscalls to the native 64-bit kernel syscalls(needs a table of 32-bit syscall numbers with funtions which get the 32-bit system call args, call the 64-bit native functions using the 64-bit values and copyconverting the returns back to 32-bit), mapping of 32-bit ioctls to functions which copy the 32-bit structs to the 64-bit structs and back for return, and other nasty things like ptrace... TDFX didn't required any AGP support, so there's work to be done there. Seems so, the x86_64 developers should be able to give some more info, e.g. I've read in arch/x86_64/kernel/pci-gart.c that the AMD Hammer has an IOMMU in the northbridge and it says that it can support PCI devices which can only support 32bit addresses on systems 4GB using the IOMMU. Nonetheless, if there is no IOMMU, then pages for HW-access would need to be allocated below 4GB. If only very few space is needed, kmalloc can be used with GFP_DMA which tells it to allocate below MAX_DMA_ADDRESS which is defined to 16MB on i386(24 address lines). x86_64 seems to support the same GFP_DMA range for compatibility. From what I have seen about 32-bit compatibility, it's best to have fixed-size data structures without 64-bit values, especially no pointers in structures which point to other data needed and also take care when adding other data types which include struct timeval which contain 32-bit seconds on 32-bit systems and 64-bit seconds(past 2038...) on 64-bit systems. If this is given, then the compatibility layer should be very easy, small and fast, no need to copyconvert 32-bit struct to 64-bit struct forth and back and no two separate struct definitions to handle. Bernd PS: I don't know much about AGP, DRI and the internals of AMD Hammer Systems, so please forgive me if I overlooked something obvious. PPS: If you want to align/use small data, I think it would be good to use something like this: uint32, uint16, uint8, uint8, uint32, ... instead of shifting or accessing bits outside of the byte range because this may cause endian problems with on Macs/PPC. --- 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] DRI CVS make World problem
I'm having trouble getting make World happening in current DRI cvs. ./config/imake/imake does exists, and the error is unclear as to whats missing make[2]: Leaving directory `/usr/src/dri/xc/xc/config/imake' make -w xmakefile make[2]: Entering directory `/usr/src/dri/xc/xc' rm -f xmakefile ./config/imake/imake -I./config/cf -s xmakefile -DTOPDIR=. -DCURDIR=. ./config/imake/imake: No such file or directory ./config/imake/imake: Cannot exec cpp -m32. Stop. my host.def file - /* * Set this for each DRI branch. It will be appended to the XFree86 version * information. */ #define XFree86CustomVersion DRI trunk #define LinuxDistribution LinuxDebian #define CcCmd gcc -m32 #define CppCmd cpp -m32 #define CplusplusCmd g++ #define LdPreLib -L$(BUILDLIBDIR) -L$(USRLIBDIR) -L/usr/X11R6/lib/ #define DefaultGcc2i386Opt -O2 -march=pentium-mmx #define BuildXFree86ConfigTools YES #define XF86CardDrivers ati vga #define DriDrivers r200 #define GccWarningOptions -Wall -Wpointer-arith -Wstrict-prototypes \ -Wmissing-prototypes -Wmissing-declarations \ -Wnested-externs #define DefaultCCOptions -ansi GccWarningOptions -pipe -g #define NormalLibGlx NO #define BuildXF86DRIYES #define BuildXF86DRMYES #define HasAgpGart NO #define HasPAM NO #define HasMTRRSupport NO #define HasMMXSupport YES #define HasSSESupport NO #define Has3DNowSupport NO #define MesaUse3DNowNO #define MesaUseSSE NO #define MesaUseMMX YES #define HasLinuxInput YES #define HasKatmaiSupportNO #define MesaUseKatmai NO #define HasGlide3 NO #define HasGnuMake YES #define XF86AFB NO #define XnestServer NO #define XVirtualFramebufferServer NO /* * Don't change anything below or the build will fail. */ #define BuildServersOnly YES #define BuildXvLibrary YES #define BuildXvMCLibrary YES #define BuildLibrariesForXServers NO #define BuildLibrariesForConfigTools NO #define BuildXIE NO #define BuildPexExt NO #define XprtServer NO #define SharedLibFont NO #define XInputDrivers mouse #if DoLoadableServer #undef XF1Bpp #undef XF4Bpp #define XF1Bpp NO #define XF4Bpp NO #endif --- 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
