[Dri-devel] DRI resume erratum
Dear lists, It seems that there are some problems with the latest Radeon DRI resume binary snapshots on http://cpbotha.net/dri_resume.html - these correspond to v6 of the resume patch. There is nothing wrong with the patch, but installing the binary snapshots over an XFree86 4.2.x installation seems to cause problems with applications that use Xft/XRENDER and is thus not recommended. I have reverted the available download to pre XFree86 HEAD merge snapshots, i.e. 20021012 and these have proven to work well when installed over a 4.2.x installation. If you're experiencing trouble with 20021203 over 4.2.x, please downgrade. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- 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] Radeon DRI Resume - quo vadis?
Dear list, In spite of some issues with binary snapshots, the DRI resume patches seem to work well. They have been available and in use on several different kinds of laptops for a few months now. What are the chances of this patch being accepted into the DRI CVS repository? How should I go about getting these small changes off my hands and eventually into XFree86? Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- 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] dri_dma_t.send_count
I've been doing a little grepping here and there. Correct me if I'm wrong, but in dri_dma_t, there are fields send_count, and related send_XXX values; these fields never seem to be used from the user level. They seem to only be used internally to the kernel driver. In which case, sounds like they do not really belong in the struct passed around for dma related ioctls in the first place. True? --- 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: Radeon: lockup on state change
Charl P. Botha wrote: On Mon, Dec 09, 2002 at 10:30:35PM +, Keith Whitwell wrote: Charl P. Botha wrote: On Mon, Dec 09, 2002 at 09:45:12PM +, Keith Whitwell wrote: There's a fix for this in recent cvs: /* Mask out highest bit, which is used by AMD for 3dnow * Newer Intel have this bit set, but do not support 3dnow */ AND_L ( CONST(0X7FFF), EAX) I still could reproduce this SIGFPE with yesterday's CVS. I just did a grep though all the .c and .h files in my DRI CVS tree for Mask out highest bit but could not find the above. In which file should this be? xc/extras/Mesa/src/X86/common_x86_asm.S Okay, I just checked and I can still reproduce a SIGFPE with today's CVS. I've made doubly sure that the new libGL is used. Here is a backtrace: Program received signal SIGFPE, Arithmetic exception. 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so (gdb) bt #0 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so #1 0x0840b6a0 in ?? () #2 0x4246c634 in init_vertex_stage (ctx=0x828d0e0, stage=0x840b174) at t_vb_vertex.c:286 #3 0x42427965 in _tnl_run_pipeline (ctx=0x828d0e0) at t_pipeline.c:154 #4 0x4247e36a in radeonWrapRunPipeline (ctx=0x828d0e0) at radeon_state.c:2089 #5 0x4242617b in _tnl_run_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:399 #6 0x424261dc in exec_vert_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:424 #7 0x4242635a in _tnl_execute_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:493 #8 0x4241d74a in _tnl_flush_immediate (ctx=0x0, IM=0x8411f60) at t_imm_api.c:77 #9 0x4241e5f1 in _tnl_Vertex3f (x=39.208, y=46.792, z=17) at t_imm_api.c:834 #10 0x422ca718 in DrawVoxelSplat (Dptr=0x46e3931c, octantIdx=@0xbfffe657, y=@0xbfffe658, z=@0xbfffe65c, prev_colour=0xbfffe8e0, ambient=@0xbfffe660, diffuse=@0xbfffe664, u=0xbfffe8a0, v=0xbfffe8b0) at /home/cpbotha/work/code/vtkcpbotha/Rendering/vtkOpenGLVolumeShellSplatMapper.cxx:113 DrawVoxelSplat is simply rendering oodles and oodles of textured quads. Any ideas? It looks like a new/different problem to the one fixed earlier. It's tempting to say it's a bug in the assembly, but otoh that code has been pretty widely used without change over the last couple of years. It may be a result of the new gcc's ability to put sse, mmx into normal code - this has bitten us a couple of times. The debugger should be able to show you the assembly instruction on which this fails. 'disassemble' is the command. 'info regs' will show the contents of the registers at this point. Basically it's standard debugging: What went wrong, why? 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] Radeon DRI Resume - quo vadis?
Charl P. Botha wrote: Dear list, In spite of some issues with binary snapshots, the DRI resume patches seem to work well. They have been available and in use on several different kinds of laptops for a few months now. What are the chances of this patch being accepted into the DRI CVS repository? How should I go about getting these small changes off my hands and eventually into XFree86? As I recall the X people on this list had some specific issues with the patches (David? Alan?) Resolving these would be the first step. Or am I lagging behind actual events? 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] dri module that can handle generic IOCTL fallbacks
Philip Brown wrote: I might have asked a varient of this many months ago.. maybe things have changed since then... Does anyone know of a dri Xserver-side video card module that will function successfully, even if the card-specific IOCTLs are not available from the kernel driver? That is to say, if DRM_IOCTL_ADD_CTX, DRM_IOCTL_DMA, and all the other DRM_IOCTL_XXX ioctls were functioning, but DRM_IOCTL_MGA_INIT, DRM_IOCTL_I810_INIT, DRM_IOCTL_I810_, and so on were not? The simplest kernel module is for the tdfx cards, I think. 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] Version handshake problems?
b/modules# glxgears Radeon DRI driver: Compatibility mode for DRM driver version 1.1.1 TCL will be disabled, expect reduced performance (prefer DRM radeon.o 1.3.x or newer) disabling TCL support glxgears: radeon_ioctl.h:165: radeonAllocCmdBuf: Assertion `rmesa-dri.drmMinor = 3' failed. Aborted systemhalted:/lib/modules# Did I miss something? :} You need to upgrade your kernel module. 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] Re: Radeon: lockup on state change
On Tue, 10 Dec 2002 10:37:07 + Keith Whitwell [EMAIL PROTECTED] wrote: Charl P. Botha wrote: On Mon, Dec 09, 2002 at 10:30:35PM +, Keith Whitwell wrote: Charl P. Botha wrote: On Mon, Dec 09, 2002 at 09:45:12PM +, Keith Whitwell wrote: There's a fix for this in recent cvs: /* Mask out highest bit, which is used by AMD for 3dnow * Newer Intel have this bit set, but do not support 3dnow */ AND_L ( CONST(0X7FFF), EAX) I still could reproduce this SIGFPE with yesterday's CVS. I just did a grep though all the .c and .h files in my DRI CVS tree for Mask out highest bit but could not find the above. In which file should this be? xc/extras/Mesa/src/X86/common_x86_asm.S Okay, I just checked and I can still reproduce a SIGFPE with today's CVS. I've made doubly sure that the new libGL is used. Here is a backtrace: Program received signal SIGFPE, Arithmetic exception. 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so (gdb) bt #0 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so #1 0x0840b6a0 in ?? () #2 0x4246c634 in init_vertex_stage (ctx=0x828d0e0, stage=0x840b174) at t_vb_vertex.c:286 #3 0x42427965 in _tnl_run_pipeline (ctx=0x828d0e0) at t_pipeline.c:154 #4 0x4247e36a in radeonWrapRunPipeline (ctx=0x828d0e0) at radeon_state.c:2089 #5 0x4242617b in _tnl_run_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:399 #6 0x424261dc in exec_vert_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:424 #7 0x4242635a in _tnl_execute_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:493 #8 0x4241d74a in _tnl_flush_immediate (ctx=0x0, IM=0x8411f60) at t_imm_api.c:77 #9 0x4241e5f1 in _tnl_Vertex3f (x=39.208, y=46.792, z=17) at t_imm_api.c:834 #10 0x422ca718 in DrawVoxelSplat (Dptr=0x46e3931c, octantIdx=@0xbfffe657, y=@0xbfffe658, z=@0xbfffe65c, prev_colour=0xbfffe8e0, ambient=@0xbfffe660, diffuse=@0xbfffe664, u=0xbfffe8a0, v=0xbfffe8b0) at /home/cpbotha/work/code/vtkcpbotha/Rendering/vtkOpenGLVolumeShellSplatMapper.cxx:113 DrawVoxelSplat is simply rendering oodles and oodles of textured quads. Any ideas? It looks like a new/different problem to the one fixed earlier. It's tempting to say it's a bug in the assembly, but otoh that code has been pretty widely used without change over the last couple of years. It may be a result of the new gcc's ability to put sse, mmx into normal code - this has bitten us a couple of times. As far as I can tell it is a bug in gcc if you get mmx instructions in normal output. It would break the kernel. As a test I once compiled my kernel with gcc-3.2 -S and grepped for %mm. All I found was some inline assembly. A workaround for the gcc-3.2 (fixed in 3.2.1) problems is to compile with -mno-mmx -mno-3dnow. The use of SSE for normal floating point operations is another thing, though. But according to gcc-3.2 docs -mfpmath=387 should be the default. The debugger should be able to show you the assembly instruction on which this fails. 'disassemble' is the command. 'info regs' will show the contents of the registers at this point. Basically it's standard debugging: What went wrong, why? Keith 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: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: Radeon: lockup on state change
On Tue, 2002-12-10 at 11:59, Felix Kühling wrote: On Tue, 10 Dec 2002 10:37:07 + Keith Whitwell [EMAIL PROTECTED] wrote: Charl P. Botha wrote: Program received signal SIGFPE, Arithmetic exception. 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so (gdb) bt #0 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so It looks like a new/different problem to the one fixed earlier. It's tempting to say it's a bug in the assembly, but otoh that code has been pretty widely used without change over the last couple of years. It may be a result of the new gcc's ability to put sse, mmx into normal code - this has bitten us a couple of times. As far as I can tell it is a bug in gcc if you get mmx instructions in normal output. It would break the kernel. As a test I once compiled my kernel with gcc-3.2 -S and grepped for %mm. All I found was some inline assembly. A workaround for the gcc-3.2 (fixed in 3.2.1) problems is to compile with -mno-mmx -mno-3dnow. The use of SSE for normal floating point operations is another thing, though. But according to gcc-3.2 docs -mfpmath=387 should be the default. This was built with gcc 2.95 (and there's no trace of a newer gcc on the system) so these 3.2 problems should not be an issue. I'll try and disassemble the offending instructions tonight as per Keith's advice. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- 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] Version handshake problems?
On Die, 2002-12-10 at 06:01, Carlos O'Donell wrote: Kernel Says: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 565M agpgart: Detected Intel 440BX chipset agpgart: AGP aperture is 64M @ 0xec00 [drm] AGP 0.99 on Intel 440BX @ 0xec00 64MB [drm] Initialized radeon 1.7.0 20020828 on minor 2 ^ ? ^^^ ? 1.7.0 is correct (where's a newer version Keith? ;), the minor 2 is about the /dev/dri/cardX device, maybe that's the problem? It uses minor 0 here. Is your DRM built with the same toolchain as the kernel etc.? Userspace Tools Say: carlos@systemhalted:~/src/dri/xc$ glxinfo name of display: :0.0 Radeon DRI driver: Compatibility mode for DRM driver version 1.1.1 ^ ? -- 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: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 DRI Resume - quo vadis?
On Tue, Dec 10, 2002 at 10:51:20AM +, Keith Whitwell wrote: Charl P. Botha wrote: Dear list, In spite of some issues with binary snapshots, the DRI resume patches seem to work well. They have been available and in use on several different kinds of laptops for a few months now. What are the chances of this patch being accepted into the DRI CVS repository? How should I go about getting these small changes off my hands and eventually into XFree86? As I recall the X people on this list had some specific issues with the patches (David? Alan?) I haven't looked at it in a while. Is there a link to it ? Alan. --- 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 DRI Resume - quo vadis?
On Tue, Dec 10, 2002 at 10:51:20AM +, Keith Whitwell wrote: Charl P. Botha wrote: Dear list, In spite of some issues with binary snapshots, the DRI resume patches seem to work well. They have been available and in use on several different kinds of laptops for a few months now. What are the chances of this patch being accepted into the DRI CVS repository? How should I go about getting these small changes off my hands and eventually into XFree86? As I recall the X people on this list had some specific issues with the patches (David? Alan?) Ah, just found a link. Looks o.k. to me now, maybe it wasn't this clean in previous attempts. Alan. --- 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 DRI Resume - quo vadis?
On Tue, 2002-12-10 at 13:13, Alan Hourihane wrote: I haven't looked at it in a while. Is there a link to it ? http://cpbotha.net/files/dri_resume/xfree86-dri-resume-v6.patch applies cleanly to current DRI CVS. http://cpbotha.net/dri_resume.html has some miscellaneous information. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- 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: Radeon: lockup on state change
Am Dienstag, 10. Dezember 2002 12:03 schrieb Charl P. Botha: On Tue, 2002-12-10 at 11:59, Felix Kühling wrote: On Tue, 10 Dec 2002 10:37:07 + Keith Whitwell [EMAIL PROTECTED] wrote: Charl P. Botha wrote: Program received signal SIGFPE, Arithmetic exception. 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so (gdb) bt #0 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so It looks like a new/different problem to the one fixed earlier. It's tempting to say it's a bug in the assembly, but otoh that code has been pretty widely used without change over the last couple of years. It may be a result of the new gcc's ability to put sse, mmx into normal code - this has bitten us a couple of times. As far as I can tell it is a bug in gcc if you get mmx instructions in normal output. It would break the kernel. As a test I once compiled my kernel with gcc-3.2 -S and grepped for %mm. All I found was some inline assembly. A workaround for the gcc-3.2 (fixed in 3.2.1) problems is to compile with -mno-mmx -mno-3dnow. The use of SSE for normal floating point operations is another thing, though. But according to gcc-3.2 docs -mfpmath=387 should be the default. This was built with gcc 2.95 (and there's no trace of a newer gcc on the system) so these 3.2 problems should not be an issue. I'll try and disassemble the offending instructions tonight as per Keith's advice. It seems that this isn't a gcc or asm thing. I use the old gcc-2.95.3, too and only some cases are fixed after the one liner. Petr Sebor did some debuging and he didn't found anything in the asm. But he thinks that the SSE routine is called with wrong data. cubemap is fixed but stex3d and texdown with pressing b sigfault. MESA_NO_SSE cure it. System is dual Athlon MP 1900+, r200. Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...done. Loaded symbols for /usr/X11R6/lib/modules/dri/r200_dri.so #0 0x40610cc9 in _mesa_sse_transform_points3_3d () from /usr/X11R6/lib/modules/dri/r200_dri.so (gdb) bt #0 0x40610cc9 in _mesa_sse_transform_points3_3d () from /usr/X11R6/lib/modules/dri/r200_dri.so #1 0x0828d8b0 in ?? () #2 0x405242b0 in default_calloc () from /usr/X11R6/lib/modules/dri/r200_dri.so #3 0xfffad7e8 in ?? () (gdb) info registers eax0x10 16 ecx0x828e6c0136898240 edx0x8050660134547040 ebx0x6 6 esp0xbfffeaec 0xbfffeaec ebp0x8056be80x8056be8 esi0x823b148136556872 edi0x828d940136894784 eip0x40610cc9 0x40610cc9 eflags 0x10206 66054 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x2b 43 gs 0x2b 43 fctrl 0x7f 127 fstat 0x0 0 ftag 0x0 0 fiseg 0x0 0 fioff 0x0 0 foseg 0x20 32 fooff 0x0 0 fop0x0 0 xmm0 0x xmm1 0x xmm2 0x xmm3 0x xmm4 0x xmm5 0x xmm6 0x xmm7 0x mxcsr 0x1f80 8064 (gdb) disassemble Dump of assembler code for function _mesa_sse_transform_points3_3d: 0x40610c64 _mesa_sse_transform_points3_3d:push %esi 0x40610c65 _mesa_sse_transform_points3_3d+1: push %edi 0x40610c66 _mesa_sse_transform_points3_3d+2: mov0x14(%esp,1),%esi 0x40610c6a _mesa_sse_transform_points3_3d+6: mov0xc(%esp,1),%edi 0x40610c6e _mesa_sse_transform_points3_3d+10: mov0x10(%esp,1),%edx 0x40610c72 _mesa_sse_transform_points3_3d+14: mov0x8(%esi),%ecx 0x40610c75 _mesa_sse_transform_points3_3d+17: test %ecx,%ecx 0x40610c77 _mesa_sse_transform_points3_3d+19: je 0x40610d02 _mesa_sse_transform_points3_3d+158 0x40610c7d _mesa_sse_transform_points3_3d+25: mov0xc(%esi),%eax 0x40610c80 _mesa_sse_transform_points3_3d+28: orl$0x7,0x14(%edi) 0x40610c84 _mesa_sse_transform_points3_3d+32: mov%ecx,0x8(%edi) 0x40610c87 _mesa_sse_transform_points3_3d+35: movl $0x3,0x10(%edi) 0x40610c8e _mesa_sse_transform_points3_3d+42: shl$0x4,%ecx 0x40610c91 _mesa_sse_transform_points3_3d+45: mov0x4(%esi),%esi 0x40610c94 _mesa_sse_transform_points3_3d+48: mov0x4(%edi),%edi 0x40610c97 _mesa_sse_transform_points3_3d+51: add%edi,%ecx 0x40610c99 _mesa_sse_transform_points3_3d+53: lea0x0(%esi,1),%esi 0x40610ca0 _mesa_sse_transform_points3_3d+60: movaps 0x0(%edx),%xmm0 0x40610ca4 _mesa_sse_transform_points3_3d+64: movaps
Re: [Dri-devel] Version handshake problems?
Michel Dänzer wrote: On Die, 2002-12-10 at 06:01, Carlos O'Donell wrote: Kernel Says: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 565M agpgart: Detected Intel 440BX chipset agpgart: AGP aperture is 64M @ 0xec00 [drm] AGP 0.99 on Intel 440BX @ 0xec00 64MB [drm] Initialized radeon 1.7.0 20020828 on minor 2 ^ ? ^^^ ? 1.7.0 is correct (where's a newer version Keith? ;), the minor 2 is about the /dev/dri/cardX device, maybe that's the problem? It uses minor 0 here. Is your DRM built with the same toolchain as the kernel etc.? Userspace Tools Say: carlos@systemhalted:~/src/dri/xc$ glxinfo name of display: :0.0 Radeon DRI driver: Compatibility mode for DRM driver version 1.1.1 ^ ? Hmm. Do you have the variable 'RADEON_COMPAT' set in your environment? The test for this message is: if ( sPriv-drmMinor 3 || getenv(RADEON_COMPAT)) 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] Radeon DRI Resume - quo vadis?
On Tue, Dec 10, 2002 at 12:17:05PM +, Alan Hourihane wrote: On Tue, Dec 10, 2002 at 10:51:20AM +, Keith Whitwell wrote: Charl P. Botha wrote: Dear list, In spite of some issues with binary snapshots, the DRI resume patches seem to work well. They have been available and in use on several different kinds of laptops for a few months now. What are the chances of this patch being accepted into the DRI CVS repository? How should I go about getting these small changes off my hands and eventually into XFree86? As I recall the X people on this list had some specific issues with the patches (David? Alan?) Ah, just found a link. Looks o.k. to me now, maybe it wasn't this clean in previous attempts. One thing though. It doesn't look like it's hooked to any APM events. It's just run generically everytime on ModeInit. What happens when you VT switch - does it handle them cases too ? Alan. --- 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 DRI Resume - quo vadis?
On Tue, 2002-12-10 at 13:36, Alan Hourihane wrote: One thing though. It doesn't look like it's hooked to any APM events. It's just run generically everytime on ModeInit. What happens when you VT switch - does it handle them cases too ? At the moment it's called from RADEONEnterVT() in radeon_driver.c - so the code is called after every VT switch. During normal operation this doesn't cause any problems as it's idempotent. I would prefer hooking it more specifically to a power event... however, last time I checked the infrastructure for non-APM power events didn't seem to be ready. Many people are using this on ACPI-only laptops with swsusp for software suspension. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- 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.o DRM modules breaks my CD player (!)
Am Samstag, 7. Dezember 2002 12:27 schrieb [EMAIL PROTECTED]: Just to say that I still have significant disk access latency and (10 seconds) lock ups on X using DRM 1.7.0 from Linux version 2.4.20-ac1 (root@trinity) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 SMP Sun Dec 1 10:56:18 GMT 2002 Its making the computer virtually unusable. I'll try to see if I can get it to load DRM 1.1.1 from an earlier kernelor perhaps just revert to an earlier kernel Kernel 2.4.20-aa1 I can only second that, even with the lasted DRI DRM module taken from yesterdays DRI CVS. No disk stuttering but some latency here and there and some Mesa demos aren't running smooth anymore. Mesa/demos ./gears 466 frames in 5.001 seconds = 93.181 FPS 5106 frames in 5.000 seconds = 1021.200 FPS 4181 frames in 5.004 seconds = 835.532 FPS 4358 frames in 5.002 seconds = 871.252 FPS 4926 frames in 5.000 seconds = 985.200 FPS Was at ~2395 FPS before. Mesa/demos ./gloss 354 frames in 5.306 seconds = 66.7169 FPS 1956 frames in 5.731 seconds = 341.302 FPS 1709 frames in 5.009 seconds = 341.186 FPS 2631 frames in 5 seconds = 526.2 FPS 857 frames in 5.168 seconds = 165.828 FPS 1815 frames in 5.259 seconds = 345.123 FPS 1899 frames in 5.54 seconds = 342.78 FPS 2014 frames in 5.88 seconds = 342.517 FPS Was at ~410 FPS before. Mesa/demos ./clearspd For options: ./clearspd -help Mode: RGB SwapBuffers: no Size: 400 x 400 Buffers: color Rate: 400 clears in 2.046s = 195.503 clears/s 3.12805e+07 pixels/s Rate: 1600 clears in 3.546s = 451.213 clears/s 7.2194e+07 pixels/s Rate: 1600 clears in 3.54s = 451.977 clears/s 7.23164e+07 pixels/s Rate: 1600 clears in 3.58s = 446.927 clears/s 7.15084e+07 pixels/s Rate: 1600 clears in 3.569s = 448.305 clears/s 7.17288e+07 pixels/s Rate: 1600 clears in 3.405s = 469.897 clears/s 7.51836e+07 pixels/s Now a tenth of the former. -Dieter --- 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 DRI Resume - quo vadis?
Keith Whitwell wrote: Charl P. Botha wrote: Dear list, In spite of some issues with binary snapshots, the DRI resume patches seem to work well. They have been available and in use on several different kinds of laptops for a few months now. What are the chances of this patch being accepted into the DRI CVS repository? How should I go about getting these small changes off my hands and eventually into XFree86? As I recall the X people on this list had some specific issues with the patches (David? Alan?) Resolving these would be the first step. Or am I lagging behind actual events? I have no concerns about the implications on the DRI with Charl's approach. He's kept everything in the driver at the mode init level, which I think is good. I'll defer any review of the actual Radeon specifics to the Radeon maintainers. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- 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.o DRM modules breaks my CD player (!)
On Tue, 2002-12-10 at 12:45, Dieter Nützel wrote: No disk stuttering but some latency here and there and some Mesa demos aren't running smooth anymore. The new DRI modules appear to be really bad from the bug reports I've received so far. Thats a bit worrying since XFree 4.3 seems to need them. Hopefully its just a small bug somewhere but the code is so foul and obfuscated I'm just going to revert the DRM code in -ac Alan --- 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] Dual screen Radeon +DRI
I have got DRI running with Dual Screens with DRI working on display :0.0 and Indirect rendering on :0.1. If I attempt to enable DRI on the second screen if fails to open /dev/dri/card0 because it is busy. It is ready used for the first screen. On failing to access the device DRI is then disabled, however since it already succefully enabled DRI, the driver gets confused later. Is there any mechanism that can be implemented to share the device between both screens? I am not looking to get Xinerama working at the moment (leave that for later). The ATI fglrx drivers claim to work with 2 Screens, not that I got them working, so it must be posible... --- 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] ATI Radeon fifo problem...
Hi, I am attempting to get DRI/DRM working on my laptop. The problem is that when I attempt to enable acceleration, X attempts to start, but I see a corrupted screen - the mouse is incorrect, the background is corrupted and none of the applications in my .xsession start up. Without acceleration, X works fine, but unaccelerated. When I inspect the XFree86.0.log file for the accerlerated I see at the end: RADEON(0): FIFO timed out, resetting engine... Followed by a number of lines stating the sub-systems are being reset and timed out. My system info: HP Pavillion ze4125 laptop. Distribution: Debian Sid, up-to-date. Kernel: version 2.4.20 with ACPI patch. XFree86: HEAD CVS downloaded on 8th Dec 2002. DRI: radeon-20021208-linux.i386.tar lspci -v output for video card: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility U1 (prog-if 00 [VGA]) Subsystem: Hewlett-Packard Company: Unknown device 0024 Flags: bus master, stepping, fast Back2Back, 66Mhz, medium devsel, latency 66, IRQ 10 Memory at e800 (32-bit, prefetchable) [size=128M] I/O ports at 9000 [size=256] Memory at e010 (32-bit, non-prefetchable) [size=64K] Expansion ROM at unassigned [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 I have checked that dma is enabled using setpci, which it is. Also I saw the same problem with older DRI drivers and older XFree86 versions (well version 4.2.1 up). When I omit the ChipID entry for the Radeon Device entry in XF86COnfig-4 I get kernel panics at the point when the driver attempts to identify the chip. I've tried ids of 0x4242 (Radeon 9000 I think), 0x4c59 (Radeon Mobility M6 LY AGP) and 0x4c5a (Radeon Mobility M6 LZ AGP), both have the same result - the above problem. I note that the Radeon Mobility U1 does not appear in the list of supported cards. Is it supported? I also note that in my kern.log I see the following message: Dec 10 11:12:58 marvin kernel: agpgart: Maximum main memory to use for agp memory: 408M Dec 10 11:12:58 marvin kernel: agpgart: unsupported bridge Dec 10 11:12:58 marvin kernel: agpgart: no supported devices found. The lspci -v for the AGP is: 00:01.0 PCI bridge: ATI Technologies Inc U1/A3 AGP Bridge [IGP 320M] (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 99 Bus: primary=00, secondary=01, subordinate=01, sec-latency=68 I/O behind bridge: 9000-9fff Memory behind bridge: e010-e01f Prefetchable memory behind bridge: e800-efff Is it possible that my problems are simply due to the fact that: a) The AGP bridge is unsupported in the kernel module. This would lead to the X driver in accelerated mode showing a fifo timeout anyway. (As the fifo is never emptied, as the video card is not servicing requests from it.) b) The ATI Mobility U1 is sufficiently different from the other ATI Mobility chips to cause a kernel panic on auto-detect. c) Thus the ATI Mobility U1 graphics chip is unsupported anyway, even if the kernel module worked. Or have I just got my configuration wrong? Can anyone advise me how I will get DRI/DRM to work on my hardware? Thanks, Jason. --- 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] Version handshake problems?
Did I miss something? :} You need to upgrade your kernel module. Tell me if there is anything else you might need. I'm a veteran at these types of problems :} but I'm stuck in exam hell right now with little time to dig, so I'm just passing off my weekly testing results. [Email not trimmed to 80 chars. Maintaining authenticity of output] CVS Fear: = Removed entire local tree and checked everything out again, rebuilt, and the problem remains. ~/.cvsrc cvs -z3 -q diff -uNp update -Pd remove -f Should be kosher and happy at keeping the tree properly pruned and synchronized. Running Kernel: === uname -a Linux systemhalted 2.4.19 #3 SMP Mon Nov 25 23:22:31 EST 2002 i686 Pentium III (Katmai) GenuineIntel GNU/Linux Built with the same toolchain as the DRI CVS tree. DRI Tree Config === ./src/dri/build/xc/config/cf/hosts.def 56 /* Optionally turn this on to force the kernel modules to build */ 57 #define BuildXF86DRM YES cp ./src/dri/build/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon.o \ /lib/modules/2.4.19/misc depmod -a -v modprobe radeon Environment Variables = I don't have any compat environment variables set. set | grep COMPAT (Shows nothing, manual inspection returns nil too). The check for minor 3 is worrying me. Why the check? Proc The two cards on my system are: 00:0d.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc.: Unknown device 0300 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: 64 Interrupt: pin A routed to IRQ 11 Region 0: Memory at ea00 (32-bit, prefetchable) [disabled] [size=16M] Region 1: Memory at e804 (32-bit, non-prefetchable) [disabled] [size=16K] Region 2: Memory at e880 (32-bit, non-prefetchable) [disabled] [size=8M] Expansion ROM at unassigned [disabled] [size=64K] 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon 7500 QW (prog-if 00 [VGA]) Subsystem: Unknown device 174b:7161 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: 66 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at f000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 9000 [size=256] Region 2: Memory at e900 (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 Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x2 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- /proc/dri shows 0, 1 and 2. 0 - tdfx 0xe200 (The Matrox) 1 - radeon 0xe201 PCI:1:0:0 (Radeon 7500 QW AGP) 2 - radeon 0xe202 (Radeon, the VGA interface?) XFree86.0.log = Attached to email. *** Small Pertinent snip *** drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: minor is 1 drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is 6, (OK) drmGetBusid returned '' (II) RADEON(0): [drm] created radeon driver at busid PCI:1:0:0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe8992000 (II) RADEON(0): [drm] mapped SAREA 0xe8992000 to 0x40012000 (II) RADEON(0): [drm] framebuffer handle = 0xf000 (II) RADEON(0): [drm] added 1 reserved context for kernel (WW) RADEON(0): [dri] Some DRI features disabled because of version mismatch. [dri] radeon.o kernel module version is 1.1.1 but 1.3.1 or later is preferred. *** c. 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.2.99.2 (DRI trunk) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 21 October 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 i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not
Re: [Dri-devel] Dual screen Radeon +DRI
Tue, 10 Dec 2002 17:14:37 +, tu as dit : I have got DRI running with Dual Screens with DRI working on display :0.0 and Indirect rendering on :0.1. If I attempt to enable DRI on the second screen if fails to open /dev/dri/card0 because it is busy. It is ready used for the first screen. On failing to access the device DRI is then disabled, however since it already succefully enabled DRI, the driver gets confused later. Is there any mechanism that can be implemented to share the device between both screens? I am not looking to get Xinerama working at the moment (leave that for later). The ATI fglrx drivers claim to work with 2 Screens, not that I got them working, so it must be posible... Are you running the cvs version or some modified dri? In both case, is it possible to see your Xfree86 config file? Thanks, Marc --- 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: Radeon: lockup on state change
Am 2002.12.10 11:59:13 +0100 schrieb(en) Felix Kühling: On Tue, 10 Dec 2002 10:37:07 + Keith Whitwell [EMAIL PROTECTED] wrote: Charl P. Botha wrote: Okay, I just checked and I can still reproduce a SIGFPE with today's CVS. I've made doubly sure that the new libGL is used. Here is a backtrace: Program received signal SIGFPE, Arithmetic exception. 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so (gdb) bt #0 0x4246fe4a in _mesa_sse_transform_points3_general () from /usr/X11R6/lib/modules/dri/radeon_dri.so #1 0x0840b6a0 in ?? () #2 0x4246c634 in init_vertex_stage (ctx=0x828d0e0, stage=0x840b174) at t_vb_vertex.c:286 #3 0x42427965 in _tnl_run_pipeline (ctx=0x828d0e0) at t_pipeline.c:154 #4 0x4247e36a in radeonWrapRunPipeline (ctx=0x828d0e0) at radeon_state.c:2089 #5 0x4242617b in _tnl_run_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:399 #6 0x424261dc in exec_vert_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:424 #7 0x4242635a in _tnl_execute_cassette (ctx=0x828d0e0, IM=0x8411f60) at t_imm_exec.c:493 #8 0x4241d74a in _tnl_flush_immediate (ctx=0x0, IM=0x8411f60) at t_imm_api.c:77 #9 0x4241e5f1 in _tnl_Vertex3f (x=39.208, y=46.792, z=17) at t_imm_api.c:834 #10 0x422ca718 in DrawVoxelSplat (Dptr=0x46e3931c, octantIdx=@0xbfffe657, y=@0xbfffe658, z=@0xbfffe65c, prev_colour=0xbfffe8e0, ambient=@0xbfffe660, diffuse=@0xbfffe664, u=0xbfffe8a0, v=0xbfffe8b0) at /home/cpbotha/work/code/vtkcpbotha/Rendering/vtkOpenGLVolumeShellSplatMapper.cxx:113 DrawVoxelSplat is simply rendering oodles and oodles of textured quads. Any ideas? It looks like a new/different problem to the one fixed earlier. It's tempting to say it's a bug in the assembly, but otoh that code has been pretty widely used without change over the last couple of years. It may be a result of the new gcc's ability to put sse, mmx into normal code - this has bitten us a couple of times. As far as I can tell it is a bug in gcc if you get mmx instructions in normal output. It would break the kernel. As a test I once compiled my kernel with gcc-3.2 -S and grepped for %mm. All I found was some inline assembly. A workaround for the gcc-3.2 (fixed in 3.2.1) problems is to compile with -mno-mmx -mno-3dnow. The use of SSE for normal floating point operations is another thing, though. But according to gcc-3.2 docs -mfpmath=387 should be the default. The debugger should be able to show you the assembly instruction on which this fails. 'disassemble' is the command. 'info regs' will show the contents of the registers at this point. Basically it's standard debugging: What went wrong, why? Keith Felix I get the same sigfpe exception as Charls, using gcc 2.95.3 (suse 7.3), kernel 2.4.20, when disabling TCL and running xmms with plugins and with other apps its maybe the same... also the backtrace is the same til step #9 HW: Radeon7500, sis745, AthlonXP1700+ Just to clarify: The SIGFPE occurs when SSE is enabled and TCL disabled, disabling only VTXFMT doesnt trigger that bug I think (now). Andreas --- 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 DRI Resume - quo vadis?
On Tue, Dec 10, 2002 at 10:31:08AM +0100, Charl P. Botha wrote: Dear list, In spite of some issues with binary snapshots, the DRI resume patches seem to work well. They have been available and in use on several different kinds of laptops for a few months now. What are the chances of this patch being accepted into the DRI CVS repository? How should I go about getting these small changes off my hands and eventually into XFree86? My memory is a little bit fuzzy on this. Did this patch also allow users to change their DRM module and radeon_dri.so file while vt switched? That is, update drivers w/o restarting X? -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRI Resume - quo vadis?
On Tue, Dec 10, 2002 at 12:53:51PM -0800, Ian Romanick wrote: On Tue, Dec 10, 2002 at 10:31:08AM +0100, Charl P. Botha wrote: Dear list, In spite of some issues with binary snapshots, the DRI resume patches seem to work well. They have been available and in use on several different kinds of laptops for a few months now. What are the chances of this patch being accepted into the DRI CVS repository? How should I go about getting these small changes off my hands and eventually into XFree86? My memory is a little bit fuzzy on this. Did this patch also allow users to change their DRM module and radeon_dri.so file while vt switched? That is, update drivers w/o restarting X? No. You're thinking of the DRI ReInit patches which I started with an ugly kludge and Michel Dänzer subsequently turned into a very good solution for swapping out agpgart and the radeon DRM without restarting X. As a side-advantage, it also allows suspending/resuming, at least if no DRI-clients are running. The patch I'm talking about above is much simpler however. It performs a hardware-only re-initialisation at VT entry so that suspend/resume works even with running DRI-clients and Xv applications. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] [BUXFIX] Linux agpgart version check
This patch fixes two problems with the version requirement check for the
Linux agpgart module in kdrive and libdrm.a:
1. The current code has faulty logic which prevents an error from ocurring
if the major version number of agpgart is equal to that required, but the
minor version is less than that required.
2. The current code will raise an error if the agpgart major version
number is higher than that required. Dave Jones, the current agpgart
maintainer, submitted some agp changes to the 2.5 kernel tree and bumped
the version number of agpgart from 0.99 to 1.0. This broke compatiblity
with current XFree86 versions, despite the fact that the interface hasn't
changed, so he had to change the version number to 0.100. I asked Dave if
a patch to XFree86 could assume future backwards compatibility and he
said:
Given that any breakage would screw over the freebsd folks too,
I'm inclined to do whatever I can to maintain backwards compatability.
For now, I'm going to bump through 0.99 - 0.100 - 0.whatever
as that matches the existing code, so we don't need to break
existing X setups. Fixing this would be good for the future
however, so one day, we can go to 1.0.
So my patch will only produce an error if the agpgart version is earlier
than the one required, assuming backwards compatibility in future
versions. This will allow bumping the agpgart major version some time in
the future, and still allows the agpgart version requirement in XFree86 to
be bumped if new functionality is required from a future agpgart version
(which again is assumed to also retain the original interface).
I plan to commit this to the DRI cvs HEAD. Please apply this to XFree86
cvs so it can be included in XFree86 4.3.0. Thanks.
--
Leif Delgass
http://www.retinalburn.net
Index: xc/programs/Xserver/hw/kdrive/linux/agp.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/kdrive/linux/agp.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 agp.c
--- xc/programs/Xserver/hw/kdrive/linux/agp.c 9 Apr 2001 16:27:42 -
1.1.1.1
+++ xc/programs/Xserver/hw/kdrive/linux/agp.c 10 Dec 2002 20:51:02 -
@@ -120,9 +120,16 @@
KdReleaseGART(-1);
#if defined(linux)
- /* Should this look for version = rather than version == ? */
- if (agpinf.version.major != AGPGART_MAJOR_VERSION
- agpinf.version.minor != AGPGART_MINOR_VERSION) {
+ /* Per Dave Jones, evey effort will be made to keep the
+* agpgart interface backwards compatible, so allow all
+* future versions.
+*/
+ if (
+#if (AGPGART_MAJOR_VERSION 0) /* quiet compiler */
+ agpinf.version.major AGPGART_MAJOR_VERSION ||
+#endif
+ (agpinf.version.major == AGPGART_MAJOR_VERSION
+agpinf.version.minor AGPGART_MINOR_VERSION)) {
fprintf(stderr,
Kernel agpgart driver version is not current
(%d.%d vs %d.%d)\n,
Index: xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c,v
retrieving revision 1.5
diff -u -r1.5 lnx_agp.c
--- xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c 11 Sep 2002 00:57:49
- 1.5
+++ xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c 10 Dec 2002 20:51:03
+-
@@ -89,9 +89,16 @@
xf86ReleaseGART(-1);
#if defined(linux)
- /* Should this look for version = rather than version == ? */
- if (agpinf.version.major != AGPGART_MAJOR_VERSION
- agpinf.version.minor != AGPGART_MINOR_VERSION) {
+ /* Per Dave Jones, evey effort will be made to keep the
+* agpgart interface backwards compatible, so allow all
+* future versions.
+*/
+ if (
+#if (AGPGART_MAJOR_VERSION 0) /* quiet compiler */
+ agpinf.version.major AGPGART_MAJOR_VERSION ||
+#endif
+ (agpinf.version.major == AGPGART_MAJOR_VERSION
+agpinf.version.minor AGPGART_MINOR_VERSION)) {
xf86DrvMsg(screenNum, X_ERROR,
GARTInit: Kernel agpgart driver version is not current
(%d.%d vs %d.%d)\n,
Re: [Dri-devel] [PATCH] [BUXFIX] Linux agpgart version check
On Tue, Dec 10, 2002 at 04:21:03PM -0500, Leif Delgass wrote:
--- xc/programs/Xserver/hw/kdrive/linux/agp.c9 Apr 2001 16:27:42 -
1.1.1.1
+++ xc/programs/Xserver/hw/kdrive/linux/agp.c10 Dec 2002 20:51:02 -
@@ -120,9 +120,16 @@
KdReleaseGART(-1);
#if defined(linux)
-/* Should this look for version = rather than version == ? */
-if (agpinf.version.major != AGPGART_MAJOR_VERSION
-agpinf.version.minor != AGPGART_MINOR_VERSION) {
+/* Per Dave Jones, evey effort will be made to keep the
^
Silly typo. 8)
Dave
--
| Dave Jones.http://www.codemonkey.org.uk
| SuSE Labs
---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] [BUGFIX] Linux agpgart version check
On Tue, 10 Dec 2002, Dave Jones wrote:
On Tue, Dec 10, 2002 at 04:21:03PM -0500, Leif Delgass wrote:
--- xc/programs/Xserver/hw/kdrive/linux/agp.c 9 Apr 2001 16:27:42 -
1.1.1.1
+++ xc/programs/Xserver/hw/kdrive/linux/agp.c 10 Dec 2002 20:51:02 -
@@ -120,9 +120,16 @@
KdReleaseGART(-1);
#if defined(linux)
- /* Should this look for version = rather than version == ? */
- if (agpinf.version.major != AGPGART_MAJOR_VERSION
- agpinf.version.minor != AGPGART_MINOR_VERSION) {
+ /* Per Dave Jones, evey effort will be made to keep the
^
Silly typo. 8)
Dave
D'oh. Thanks...here it is again with the the subject line fixed too, just
in case it missed anyone's filter. ;)
--
Leif Delgass
http://www.retinalburn.net
Index: xc/programs/Xserver/hw/kdrive/linux/agp.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/kdrive/linux/agp.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 agp.c
--- xc/programs/Xserver/hw/kdrive/linux/agp.c 9 Apr 2001 16:27:42 -
1.1.1.1
+++ xc/programs/Xserver/hw/kdrive/linux/agp.c 10 Dec 2002 20:51:02 -
@@ -120,9 +120,16 @@
KdReleaseGART(-1);
#if defined(linux)
- /* Should this look for version = rather than version == ? */
- if (agpinf.version.major != AGPGART_MAJOR_VERSION
- agpinf.version.minor != AGPGART_MINOR_VERSION) {
+ /* Per Dave Jones, every effort will be made to keep the
+* agpgart interface backwards compatible, so allow all
+* future versions.
+*/
+ if (
+#if (AGPGART_MAJOR_VERSION 0) /* quiet compiler */
+ agpinf.version.major AGPGART_MAJOR_VERSION ||
+#endif
+ (agpinf.version.major == AGPGART_MAJOR_VERSION
+agpinf.version.minor AGPGART_MINOR_VERSION)) {
fprintf(stderr,
Kernel agpgart driver version is not current
(%d.%d vs %d.%d)\n,
Index: xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c,v
retrieving revision 1.5
diff -u -r1.5 lnx_agp.c
--- xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c 11 Sep 2002 00:57:49
- 1.5
+++ xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_agp.c 10 Dec 2002 20:51:03
+-
@@ -89,9 +89,16 @@
xf86ReleaseGART(-1);
#if defined(linux)
- /* Should this look for version = rather than version == ? */
- if (agpinf.version.major != AGPGART_MAJOR_VERSION
- agpinf.version.minor != AGPGART_MINOR_VERSION) {
+ /* Per Dave Jones, every effort will be made to keep the
+* agpgart interface backwards compatible, so allow all
+* future versions.
+*/
+ if (
+#if (AGPGART_MAJOR_VERSION 0) /* quiet compiler */
+ agpinf.version.major AGPGART_MAJOR_VERSION ||
+#endif
+ (agpinf.version.major == AGPGART_MAJOR_VERSION
+agpinf.version.minor AGPGART_MINOR_VERSION)) {
xf86DrvMsg(screenNum, X_ERROR,
GARTInit: Kernel agpgart driver version is not current
(%d.%d vs %d.%d)\n,
[Dri-devel] Please respond: Guaranteed Lowest Mortgage Rates!
Let lenders compete for
your
business!
*5.25%
30 Yr Fixed Rate Mortgage!
Interest rates are at their lowest point in 40 years! We help you
find the best rate for your situation by matching your needs with
hundreds of lenders! Home Improvement, Refinance, Second Mortgage,
Home Equity Loans, and More! Even with less than perfect credit
Click Here for a Free Quote!
Lock In YOUR LOW FIXED RATE TODAY
* NO COST OUT OF POCKET
* NO OBLIGATION
* FREE CONSULTATION
* ALL CREDIT GRADES ACCEPTED
Rates as low as 5.25% won't stay this low forever CLICK HERE!
Anti-SPAM
Policy Disclaimer: Under Bill s.1618 Title III passed by the 105th U.
S. Congress, mail cannot be considered spam as long as we include contact
information and a remove link for removal from this mailing list. If this
e-mail is unsolicited, please accept our apologies. Per the proposed H.R.
3113 Unsolicited Commercial Electronic Mail Act of 2000, further
transmission
to you by the sender may be stopped at NO COST to you!
Remove
8015lafV8-700WuOm3887pniS8-186DRfL7342XXEy5-139pZfl47N¬±ùÞµéX¬²'²Þu¼ØFæ> ¬*Á«y«QzÊhÈXÈ·®{hºÇ²¢ê飫jÓ ÛOz·è®f§qà¨x
©çzXm¶ÿ z÷!jyÞàü:âuëÞf¢)à+-¸z÷¥+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèýÚâuëÞ
Re: [Dri-devel] Radeon DRI Resume - quo vadis?
On Tue, Dec 10, 2002 at 01:45:09PM +0100, Charl P. Botha wrote: On Tue, 2002-12-10 at 13:36, Alan Hourihane wrote: One thing though. It doesn't look like it's hooked to any APM events. It's just run generically everytime on ModeInit. What happens when you VT switch - does it handle them cases too ? At the moment it's called from RADEONEnterVT() in radeon_driver.c - so the code is called after every VT switch. During normal operation this doesn't cause any problems as it's idempotent. I would prefer hooking it more specifically to a power event... however, last time I checked the infrastructure for non-APM power events didn't seem to be ready. Many people are using this on ACPI-only laptops with swsusp for software suspension. If you're restoring HW state required for the correct operation of the driver, and especially if it's state that something else driving the video card might change while the X server doesn't have control over it, then it should be done from EnterVT(). As a general rule, any HW state that's set in ScreenInit() should also be set in EnterVT(). By default, XFree86 handles APM events via EnterVT/LeaveVT. It's possible for a driver to provide a separate function to handle PM events, but in most cases it shouldn't be needed. I just had another look at your patch, and I didn't see any obvious problem with the way it's structured. Send it to [EMAIL PROTECTED], and Kevin Martin can review it. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Floating point exception
hello out there, I have a problem with the current dri cvs (trunk) for a Rage 128. the odd thing is that I got the damn thing to work (nicely), but with all programming i think i found a bug in the dri side of Mesa 5.0.(if that makes any sence.) ok, glxinfo output:: display: :0 screen: 0 direct rendering: Yes 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 DRI Rage128 20021125 AGP 1x x86/MMX/SSE OpenGL version string: 1.2 Mesa 5.0 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_window_pos, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess ok dri is working but glean spits this out:: $GLEAN_ROOT/bin/glean -r ll -v -- This trivial test simply verifies the internal support for basic tests. It is run on every OpenGL-capable drawing surface configuration that supports creation of a window. basic: PASS rgb8, z24, win+pmap, id 35 basic: PASS rgb8, z24, s8, win+pmap, id 36 basic: PASS rgb8, z24, accrgb16, win+pmap, id 37 basic: PASS rgb8, z24, s8, accrgb16, win+pmap, id 38 basic: PASS rgb8, db, z24, win+pmap, id 39 basic: PASS rgb8, db, z24, s8, win+pmap, id 40 basic: PASS rgb8, db, z24, accrgb16, win+pmap, id 41 basic: PASS rgb8, db, z24, s8, accrgb16, win+pmap, id 42 basic: PASS rgb8, z24, win+pmap, id 43 basic: PASS rgb8, z24, s8, win+pmap, id 44 basic: PASS rgb8, z24, accrgb16, win+pmap, id 45 basic: PASS rgb8, z24, s8, accrgb16, win+pmap, id 46 basic: PASS rgb8, db, z24, win+pmap, id 47 basic: PASS rgb8, db, z24, s8, win+pmap, id 48 basic: PASS rgb8, db, z24, accrgb16, win+pmap, id 49 basic: PASS rgb8, db, z24, s8, accrgb16, win+pmap, id 50 -- This trivial test simply verifies the internal support for basic performance tests. It is run on every OpenGL-capable drawing surface configuration that supports creation of a window. If everything is working correctly, each result should be close to 0.1 second. basicPerf: PASS rgb8, z24, win+pmap, id 35 Average = 0.109621 Range = [0.109343, 0.109771] basicPerf: PASS rgb8, z24, s8, win+pmap, id 36 Average = 0.109803 Range = [0.109752, 0.109829] basicPerf: PASS rgb8, z24, accrgb16, win+pmap, id 37 Average = 0.109669 Range = [0.109416, 0.109897] basicPerf: PASS rgb8, z24, s8, accrgb16, win+pmap, id 38 Average = 0.109688 Range = [0.109449, 0.109809] basicPerf: PASS rgb8, db, z24, win+pmap, id 39 Average = 0.109066 Range = [0.10888, 0.109413] basicPerf: PASS rgb8, db, z24, s8, win+pmap, id 40 Average = 0.108873 Range = [0.10883, 0.108899] basicPerf: PASS rgb8, db, z24, accrgb16, win+pmap, id 41 Average = 0.108224 Range = [0.10694, 0.108873] basicPerf: PASS rgb8, db, z24, s8, accrgb16, win+pmap, id 42 Average = 0.108193 Range = [0.106623, 0.109109] basicPerf: PASS rgb8, z24, win+pmap, id 43 Average = 0.109771 Range = [0.109755, 0.109794] basicPerf: PASS rgb8, z24, s8, win+pmap, id 44 Average = 0.109717 Range = [0.109566, 0.109944] basicPerf: PASS rgb8, z24, accrgb16, win+pmap, id 45 Average = 0.109748 Range = [0.109742, 0.109753] basicPerf: PASS rgb8, z24, s8, accrgb16, win+pmap, id 46 Average = 0.109786 Range = [0.109747, 0.109834] basicPerf: PASS rgb8, db, z24, win+pmap, id 47 Average = 0.108785 Range = [0.108727, 0.108837] basicPerf: PASS rgb8, db, z24, s8, win+pmap, id 48 Average = 0.108742 Range = [0.108573, 0.109001] basicPerf: PASS rgb8, db, z24, accrgb16, win+pmap, id 49 Average = 0.10828 Range = [0.106934, 0.109027] basicPerf: PASS rgb8, db, z24, s8, accrgb16, win+pmap, id 50 Average = 0.108985 Range = [0.10871, 0.109315]
