Re: [Dri-devel] radeon_lighting.c needed?
Roland Scheidegger wrote: Now that I've commited the lighting changes for r200 (still has the material fallback though), I've wanted to commit the same changes (well not exactly the same of course ;-)) to the radeon driver too (some brief testing showed it worked just fine). But I'm a bit confused, the code I'll need to touch is both in radeon_state.c as well as radeon_lighting.c. As far as I can see, radeon_lighting.c is an attempt to separate some code out of the radeon_state.c but the file is not used anywhere. So, should I still update this file too? I think it's a bit ugly to have duplicated code... I think it can be left alone at this point. Keith --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage: integrated driver
On Mon, 9 Feb 2004 16:40:19 -0800 (PST) Alex Deucher [EMAIL PROTECTED] wrote: I think I fixed the problem that caused your prosavage to fail. I forgot to add PROSAVAGEDDR and TWISTER to the bci setup function (SavageInitialize2d()) in savage_accel.c. That should fix it, but I don't have a DDR to test on. Yes it works. Thanks! One new problem. Well not new, I just didn't see it as an individual problem before. I use vesafb on my notebook with 1024x768, 8bit color depth. X always seems to restore a text mode when I switch consoles. Of course the kernel still thinks its in graphics mode. So the text console is still unreadable for me. Alex Regards, Felix --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive: On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote: [ Following up to the dri-devel mailing list, we aren't really using the sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ] On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: I just ported the latest CVS drm-kernel code into the 2.6.2 vanilla kernel. Do you have a patch for us to look at? Yes, I think I posted it to the SourceForge bug tracker. It's down right now, or I'd be including a bug ID #. Does the same problem occur if you just build the DRM from DRI CVS? It won't compile. Aside from a small number of API changes, the Makefile.linux is *severely* broken about include directories under 2.6. I use only 2.6.x. There is No problem with DRI CVS (DRM). But some apps hang the graphics card (hard). UT2003 Citadel after some (= 3) seconds. But _very_ smooth with S3TC and Roland's hardware TCL patch. Daniel any ideas? What's different compared to the standard demo? I've played it for nearly 15 minutes without a hitch. TMU3? - More triangels? (The grass)? SuSE-9.0, kernel 2.6.2-0 Greetings, Dieter --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
Dieter Nützel wrote: Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive: On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote: [ Following up to the dri-devel mailing list, we aren't really using the sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ] On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: I just ported the latest CVS drm-kernel code into the 2.6.2 vanilla kernel. Do you have a patch for us to look at? Yes, I think I posted it to the SourceForge bug tracker. It's down right now, or I'd be including a bug ID #. Does the same problem occur if you just build the DRM from DRI CVS? It won't compile. Aside from a small number of API changes, the Makefile.linux is *severely* broken about include directories under 2.6. I use only 2.6.x. There is No problem with DRI CVS (DRM). But some apps hang the graphics card (hard). UT2003 Citadel after some (= 3) seconds. But _very_ smooth with S3TC and Roland's hardware TCL patch. That's not good. There is nothing (both in the S3TC patch as well as in the changed lighting code) which could make lockups disappear. Using compressed textures shouldn't change anything (except the textures are smaller so less texture swapping is needed which might mean there are more free dma buffers available). The lighting changes did avoid some TCL fallback with materials between begin/end (and it looks like the fallback doesn't always work correctly, though I don't think it causes lockups), but in the latest patch (submitted to cvs yesterday) it's back in (as removing it wasn't correct and sometimes caused obvious rendering errors, it still awaits a proper fix). The patch still avoids a tcl fallback when using two-sided materials, but that really shouldn't have caused lockups... Meaning if the lockups have disappeared in UT2003, they are likely to reappear somewhere else. That said, I just tried to reproduce the lockups, but I can't even get ut2003 (demo 2206) to start here, it crashes even before the nvidia logo appears (seems to segfault and then be stuck waiting for a signal, killall -9 will just get rid of it fine). I can only hope it's not caused by the lighting changes I've commited yesterday (though I've no idea how these changes could cause that) - maybe some of the experimental code I've got here causes it. Roland --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRM+ATI-Radeon-Mobility
I can confirm that doing a warm reboot from 4.2.22 to 4.2.24 solves the problem and that glxgears works. Greg Wilkins wrote: I think I'm having a similar problem on my IBM a30p. I just upgraded the kernel from 2.4.22 to 2.4.24 and now DRI applications (eg glxgears) lock the machine up. I have not tried doing a warm restart between 22 and 24, but will do so after this message to see if it is the same. I am using Debian testing release with stock standard 686 kernels and xfree86-4.2.1-15. [545] LIBGL_DEBUG=verbose glxinfo name of display: :0.0 libGL: XF86DRIGetClientDriverName: 4.0.1 radeon (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/radeon_dri.so libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/radeon_dri.so drmOpenByBusid: busid is PCI:1:0:0 drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports PCI:1:0:0 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 Radeon 20010402 AGP 1x x86/MMX OpenGL version string: 1.2 Mesa 3.4.2 OpenGL extensions: GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers, GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp 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 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 Slow 0x25 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 Slow 0x29 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow [EMAIL PROTECTED]: ~ [546] ldd /usr/bin/X11/glxinfo libGLU.so.1 = /usr/X11R6/lib/libGLU.so.1 (0x40024000) libGL.so.1 = /usr/X11R6/lib/libGL.so.1 (0x4009f000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x40112000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x40121000) libpthread.so.0 = /lib/libpthread.so.0 (0x401e7000) libm.so.6 = /lib/libm.so.6 (0x40238000) libc.so.6 = /lib/libc.so.6 (0x4025a000) libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x4038c000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x40443000) libdl.so.2 = /lib/libdl.so.2 (0x4044c000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) [EMAIL PROTECTED]: ~ [547] uname -a Linux brick 2.4.24-1-686 #1 Tue Jan 6 21:29:44 EST 2004 i686 GNU/Linux If I come back from the crashes... I'll post the results of attempting a warm restart between 4.2.22 running glxgears and 4.2.24 cheers -- Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462 Mort Bay Consulting Australia and UK. http://www.mortbay.com --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage: integrated driver
--- Felix Kühling [EMAIL PROTECTED] wrote: On Mon, 9 Feb 2004 16:40:19 -0800 (PST) Alex Deucher [EMAIL PROTECTED] wrote: I think I fixed the problem that caused your prosavage to fail. I forgot to add PROSAVAGEDDR and TWISTER to the bci setup function (SavageInitialize2d()) in savage_accel.c. That should fix it, but I don't have a DDR to test on. Yes it works. Thanks! One new problem. Well not new, I just didn't see it as an individual problem before. I use vesafb on my notebook with 1024x768, 8bit color depth. X always seems to restore a text mode when I switch consoles. Of course the kernel still thinks its in graphics mode. So the text console is still unreadable for me. hmmm... that's probably because I used the SetTextMode() bios call on close screen and VT switches. I'll have dig into that more and see if I can get it working with just save and restore. I don't use a fb driver usually. I may ask Tim about it since I haven't had much luck tracking down what causes the corruption. Does it work with S3's driver? they used a bios function to restore text mode too. If so I'll have to see what's different with their code. Alex Regards, Felix __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: DRM+ATI-Radeon-Mobility
On Tue, 2004-02-10 at 13:36, Greg Wilkins wrote: I can confirm that doing a warm reboot from 4.2.22 to 4.2.24 solves the problem and that glxgears works. Some random ideas to try and further track down the problem: * make a diff of drivers/char/drm between kernels 2.4.22 and 2.4.24, and check it for obvious regressions on hardware initialisation * move the contents of drivers/char/drm from kernel 2.4.22 to 2.4.24 and/or vice versa, and see if it still works/breaks -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New DRM design (was ATI I2C, MONID)
--- Ville Syrjälä [EMAIL PROTECTED] wrote: And finally I find the current situation with multi-head cards quite bad. I'd like the ablitity for a user space app to open the whole card as one entity. That includes all CRTCs, outputs and the whole memory (minus whatever is in use by other stuff like DMA stuff and video capture). If the app doesn't want to handle such details it would just get whatever is used by the current VT. This is exactly what we are trying to stop. Right now user space apps are writing whatever they want to the video card. Now think about what has to happen on a VT switch. Don't forget that the app in the next VT can be doing the exactly the same thing and writing whatever it wants to the video hardware. Every register of the card has to be saved and restored. We have to have special code that looks for an active CP or DMA and wait for it finish and then save it's state then start DMA and the CP with the new VT's data. We have to unload up to 1GB of VRAM and load it again with fresh content. AGP memory has to be saved/restored. MTRR's have to be set. We have to sort out pending interrupts. It is also a security nightmare. User space access to the video hardware can be used to root the machine. The VT system was not designed as a multitasking system for video device drivers. If you want to write a system that saves all of this state, I'd be happy to look at it. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Build guide
I'm building Dave Airlie's mach64-0-0-7-branch and I notice the build guide (http://dri.sourceforge.net/doc/building.html) has still not been updated to include the mesa-newtree stuff. Shouldn't something like the following be added between steps 2 and 3? - 2.1) You'll also need to check out mesa, as it is no longer included in DRI cvs: cvs -d:pserver:[EMAIL PROTECTED]:/cvs/mesa login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/mesa co Mesa 2.2) Next you should modify the host.def file to point to the location where you checked out mesa: in xc/xc/config/cf/host.def you should have something like this: #define MesaSrcDir /path/to/Mesa -- I had to find this digging through archives. -James --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New DRM design (was ATI I2C, MONID)
On Tue, 2004-02-10 at 07:37, Ville Syrjl wrote: On Sun, Feb 08, 2004 at 08:27:17PM -0800, Jon Smirl wrote: Here's a quick and dirty chart of how I think things should be organised. -- user space --- | fbdev + fbcon | drm | -- memory manager/arbitration/DMA/irq -- I basically agree with this. I want to bypass the drm to do accel from user space. Doing an ioctl() for each blit feels very expensive. Rather than do an ioctl() for each blit the drm could check the commands in the DMA buffer for bad stuff. But that doesn't feel very efficient either. FWIW, that's more or less how the current radeon DRM works, and the verification doesn't seem to appear on the oprofile radar. If you don't care about the security I think you should be allowed to bypass it to gain some speed. Doesn't seem to be necessary or even useful but is very dangerous in my experience. And of course there may be cards without DMA so you may need the ability to do MMIO stuff directly. That should really only be granted to privileged processes, if at all. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Savage: integrated driver
On Tue, 10 Feb 2004 06:46:16 -0800 (PST) Alex Deucher [EMAIL PROTECTED] wrote: --- Felix K_hling [EMAIL PROTECTED] wrote: [snip] hmmm... that's probably because I used the SetTextMode() bios call on close screen and VT switches. I'll have dig into that more and see if I can get it working with just save and restore. I don't use a fb driver usually. I may ask Tim about it since I haven't had much luck tracking down what causes the corruption. Does it work with S3's driver? they used a bios function to restore text mode too. If so I'll have to see what's different with their code. Yes, both the S3 driver and Tim's original driver (with and without bios) restored the correct graphics mode. Felix --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
Michel Dnzer wrote: Works perfectly here... Do you have current DRI CVS from freedesktop.org? If so, please post the errors. Speaking of that, I've seen some users get dri cvs from sourceforge.net accidentally. Couldn't someone commit a fix so when you try to build it you just get some error (preferably written in ALL_CAPS ;)) like it's outdated, use cvs from freedesktop instead. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa / DRI r200 crashes
Roland Scheidegger wrote: I get a lot of dri crashes, were there some changes very recently in the tnl code? The crashes sometimes are predictable (for instance in the old ut it'll always crash in the intro when the announcer says in twenty-two ninety- segfault!) gdb says this: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 4566)] 0x458bce72 in ?? () (gdb) bt #0 0x458bce72 in ?? () #1 0x3cace852 in neutral_VertexAttrib2fvNV (index=9, v=0xa3812f4) at vtxfmt_tmp.h:384 #2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828 #3 0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408, start=29, count=34) at t_array_api.c:57 #4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768) at t_array_api.c:153 This looks like something which Brian has been working on recently. Keith --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa / DRI r200 crashes
Keith Whitwell wrote: Roland Scheidegger wrote: I get a lot of dri crashes, were there some changes very recently in the tnl code? The crashes sometimes are predictable (for instance in the old ut it'll always crash in the intro when the announcer says in twenty-two ninety- segfault!) gdb says this: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 4566)] 0x458bce72 in ?? () (gdb) bt #0 0x458bce72 in ?? () #1 0x3cace852 in neutral_VertexAttrib2fvNV (index=9, v=0xa3812f4) at vtxfmt_tmp.h:384 #2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828 #3 0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408, start=29, count=34) at t_array_api.c:57 #4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768) at t_array_api.c:153 This looks like something which Brian has been working on recently. Roland, can you back up to _ae_loopback_array_elt() and 'print *at-array'? My guess is that the src pointer is invalid for some reason. The pointer arithmetic looks OK though. Basically, the glArrayElement() fallback code wasn't handling glVertexAttrib arrays. I added that and expressed the multi-texcoord arrays in terms of vertex attribs. Vertex attribute 9 corresponds to texcoord array 1. In gdb, also check if at-array == ctx-Array.TexCoord[1]. -Brian --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] SIGSEGV with ut2003_demo and radeon
just tried to run ut2003_demo with radeon_dri.so from current DRI-cvs/MESA-cvs HEAD and got a SIGSEGV, just before the logo usually is displayed. However ut2003_demo worked well with an older radeon_dri.so from xfree-cvs (20031226) I had lying around and it worked with radeon_dri.so from DRI-CVS before Mesa-newtree merge (20031130). (I tried to build DRI with Mesa-cvs mesa_6_0_branch: doesnt build; and DRI CVS HEAD without a mesa-tree doesnt build, too..; but thats another story...) I got this backtrace when just running ut2003_demo: Backtrace: [ 1] ./Core.so(appGetProcReturnCode__FPvPi+0x516) [0x40a0778a] [ 2] /lib/libpthread.so.0(pthread_kill+0x174) [0x40dacbc4] [ 3] /lib/libc.so.6(__libc_sigaction+0x138) [0x40bc07f8] [ 4] /usr/X11R6/lib/modules/dri/radeon_dri.so(__driUtilCreateScreen+0x58f4) [0x43db00a4] [ 5] /usr/X11R6/lib/modules/dri/radeon_dri.so(__driUtilCreateScreen+0xfb0a1) [0x43ea5851] [ 6] /usr/X11R6/lib/modules/dri/radeon_dri.so(__driUtilCreateScreen+0xfb5f2) [0x43ea5da2] [ 7] /home/as/ut2003_demo/System/OpenGLDrv.so(DrawPrimitive__22FOpenGLRenderInterface14EPrimitiveType+0x373) [0x42f8faeb] [ 8] ./Engine.so(Render__20FStaticMeshBatchListP10FSceneNodeP16FRenderInterface+0x2b2) [0x40375d66] [ 9] ./Engine.so(RenderLevel__FP15FLevelSceneNodeP16FRenderInterface+0x22df) [0x40368f23] [10] ./Engine.so(Render__15FLevelSceneNodeP16FRenderInterface+0x7a2) [0x4034b38a] [11] ./Engine.so(Render__16FPlayerSceneNodeP16FRenderInterface+0x330) [0x403504ec] [12] ./Engine.so(Draw__11UGameEngineP9UViewportiPUcPi+0x3fe) [0x4028808a] [13] /home/as/ut2003_demo/System/SDLDrv.so(Repaint__12USDLViewporti+0x33) [0x42f5093b] [14] /home/as/ut2003_demo/System/SDLDrv.so(Tick__10USDLClient+0x85) [0x42f4f365] [15] ./Engine.so(Tick__11UGameEnginef+0x31bd) [0x4028f2e1] [16] ./ut2003-bin(_start+0x86d) [0x8051b1d] [17] ./ut2003-bin(main+0x328c) [0x8058b2c] [18] /lib/libc.so.6(__libc_start_main+0xbe) [0x40baf7ee] [19] ./ut2003-bin(_start+0x21) [0x80512d1] Signal: SIGSEGV [segmentation fault] Aborting. after modifying the ut2003_demo script to start gdb instead of ut2003-bin, I got this backtrace from gdb: (gdb) exec-file ../System/ut2003-bin (gdb) r Starting program: /home/as/ut2003_demo/System/../System/ut2003-bin (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 1024 (LWP 31522)] (no debugging symbols found)...[New Thread 2049 (LWP 31523)] Delayed SIGSTOP caught for LWP 31523. [New Thread 1026 (LWP 31524)] Delayed SIGSTOP caught for LWP 31524. (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 2051 (LWP 31525)] Delayed SIGSTOP caught for LWP 31525. Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 1024 (LWP 31522)] 0x43ec44f4 in _mesa_test_os_sse_exception_support () from /usr/X11R6/lib/modules/dri/radeon_dri.so (gdb) thread [Current thread is 1 (Thread 1024 (LWP 31522))] (gdb) c Continuing. Xlib: extension XiG-SUNDRY-NONSTANDARD missing on display :0.0. Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) back #0 0x in ?? () #1 0x43ea593a in _tnl_draw_range_elements (ctx=0x92ac188, mode=4, max_index=32, index_count=48, indices=0x91ef0c0) at t_array_api.c:118 #2 0x43ea5d94 in _tnl_DrawRangeElements (mode=4, start=0, end=31, count=48, type=5123, indices=0x8f94140) at t_array_api.c:341 #3 0x42f8faeb in FOpenGLRenderInterface::DrawPrimitive () from /home/as/ut2003_demo/System/OpenGLDrv.so #4 0x40355532 in FBspDrawList::Render () from ./Engine.so #5 0x40368edf in RenderLevel () from ./Engine.so #6 0x4034b38a in FLevelSceneNode::Render () from ./Engine.so #7 0x403504ec in FPlayerSceneNode::Render () from ./Engine.so #8 0x4028abf2 in UGameEngine::Draw () from ./Engine.so #9 0x42f5093b in USDLViewport::Repaint () from /home/as/ut2003_demo/System/SDLDrv.so #10 0x42f4f365 in USDLClient::Tick () from /home/as/ut2003_demo/System/SDLDrv.so #11 0x4028f2e1 in UGameEngine::Tick () from ./Engine.so #12 0x08051b1d in ?? () #13 0x08058b2c in ?? () #14 0x40baf7ee in __libc_start_main () from /lib/libc.so.6 (gdb) thread [Current thread is 1 (Thread 1024 (LWP 31522))] (gdb) up #1 0x43ea593a in _tnl_draw_range_elements (ctx=0x92ac188, mode=4, max_index=32, index_count=48, indices=0x91ef0c0) at t_array_api.c:118 118 tnl-Driver.RunPipeline( ctx ); (gdb) list 113*/ 114 GLuint enabledArrays = ctx-Array._Enabled | (ctx-Array._Enabled 16); 115 /* Note that arrays may have changed before/after execution. 116
Re: [Dri-devel] Mesa / DRI r200 crashes
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently in
the tnl code? The crashes sometimes are predictable (for instance in
the old ut it'll always crash in the intro when the announcer says
in twenty-two ninety- segfault!)
gdb says this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4566)]
0x458bce72 in ?? ()
(gdb) bt
#0 0x458bce72 in ?? ()
#1 0x3cace852 in neutral_VertexAttrib2fvNV (index=9, v=0xa3812f4) at
vtxfmt_tmp.h:384
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
#3 0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408,
start=29, count=34) at t_array_api.c:57
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768)
at t_array_api.c:153
This looks like something which Brian has been working on recently.
Roland, can you back up to _ae_loopback_array_elt() and 'print *at-array'?
Certainly.
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print *at-array
$1 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr = 0xa38104c
ø\005\202?ø\005\202?, Enabled = 1,
Normalized = 0 '\0', BufferObj = 0xa39aae0, _MaxElement = 20,
Flags = 1}
My guess is that the src pointer is invalid for some reason. The
pointer arithmetic looks OK though.
Basically, the glArrayElement() fallback code wasn't handling
glVertexAttrib arrays. I added that and expressed the multi-texcoord
arrays in terms of vertex attribs. Vertex attribute 9 corresponds to
texcoord array 1.
In gdb, also check if at-array == ctx-Array.TexCoord[1].
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print at-array
$4 = (const struct gl_client_array *) 0xa3b2c38
(gdb) print ctx-Array.TexCoord[1]
Cannot access memory at address 0x14d89
(2 levels up)
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768) at
t_array_api.c:153
153 fallback_drawarrays( ctx, mode, start, start + count );
(gdb) print ctx-Array.TexCoord[1]
$5 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr = 0xa381054
, Enabled = 1, Normalized = 0 '\0',
BufferObj = 0xa39aae0, _MaxElement = 20, Flags = 1}
Roland
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa / DRI r200 crashes
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently in
the tnl code? The crashes sometimes are predictable (for instance in
the old ut it'll always crash in the intro when the announcer says
in twenty-two ninety- segfault!)
gdb says this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4566)]
0x458bce72 in ?? ()
(gdb) bt
#0 0x458bce72 in ?? ()
#1 0x3cace852 in neutral_VertexAttrib2fvNV (index=9, v=0xa3812f4)
at vtxfmt_tmp.h:384
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
#3 0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408,
start=29, count=34) at t_array_api.c:57
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768)
at t_array_api.c:153
This looks like something which Brian has been working on recently.
Roland, can you back up to _ae_loopback_array_elt() and 'print
*at-array'?
Certainly.
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print *at-array
$1 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr = 0xa38104c
ø\005\202?ø\005\202?, Enabled = 1,
Normalized = 0 '\0', BufferObj = 0xa39aae0, _MaxElement = 20,
Flags = 1}
My guess is that the src pointer is invalid for some reason. The
pointer arithmetic looks OK though.
Basically, the glArrayElement() fallback code wasn't handling
glVertexAttrib arrays. I added that and expressed the multi-texcoord
arrays in terms of vertex attribs. Vertex attribute 9 corresponds to
texcoord array 1.
In gdb, also check if at-array == ctx-Array.TexCoord[1].
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print at-array
$4 = (const struct gl_client_array *) 0xa3b2c38
(gdb) print ctx-Array.TexCoord[1]
Cannot access memory at address 0x14d89
(2 levels up)
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768) at
t_array_api.c:153
153 fallback_drawarrays( ctx, mode, start, start + count );
(gdb) print ctx-Array.TexCoord[1]
$5 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr = 0xa381054
, Enabled = 1, Normalized = 0 '\0',
BufferObj = 0xa39aae0, _MaxElement = 20, Flags = 1}
Two things:
1. It's strange that ctx-Array.TexCoord[1] is an invalid address in
_ae_loopback_array_elt() but valid in _tnl_DrawArrays().
2. The count parameter to _tnl_DrawArrays() is _really_ large. What's
up with that?
-Brian
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa / DRI r200 crashes
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance in the old ut it'll always crash in the intro when the
announcer says in twenty-two ninety- segfault!)
gdb says this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4566)]
0x458bce72 in ?? ()
(gdb) bt
#0 0x458bce72 in ?? ()
#1 0x3cace852 in neutral_VertexAttrib2fvNV (index=9, v=0xa3812f4)
at vtxfmt_tmp.h:384
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at
api_arrayelt.c:828
#3 0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408,
start=29, count=34) at t_array_api.c:57
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6,
count=171564768) at t_array_api.c:153
This looks like something which Brian has been working on recently.
Roland, can you back up to _ae_loopback_array_elt() and 'print
*at-array'?
Certainly.
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print *at-array
$1 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa38104c ø\005\202?ø\005\202?, Enabled = 1,
Normalized = 0 '\0', BufferObj = 0xa39aae0, _MaxElement =
20, Flags = 1}
My guess is that the src pointer is invalid for some reason. The
pointer arithmetic looks OK though.
Basically, the glArrayElement() fallback code wasn't handling
glVertexAttrib arrays. I added that and expressed the multi-texcoord
arrays in terms of vertex attribs. Vertex attribute 9 corresponds to
texcoord array 1.
In gdb, also check if at-array == ctx-Array.TexCoord[1].
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print at-array
$4 = (const struct gl_client_array *) 0xa3b2c38
(gdb) print ctx-Array.TexCoord[1]
Cannot access memory at address 0x14d89
(2 levels up)
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768)
at t_array_api.c:153
153 fallback_drawarrays( ctx, mode, start, start + count );
(gdb) print ctx-Array.TexCoord[1]
$5 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa381054 , Enabled = 1, Normalized = 0 '\0',
BufferObj = 0xa39aae0, _MaxElement = 20, Flags = 1}
Two things:
1. It's strange that ctx-Array.TexCoord[1] is an invalid address in
_ae_loopback_array_elt() but valid in _tnl_DrawArrays().
2. The count parameter to _tnl_DrawArrays() is _really_ large. What's
up with that?
I believe both problems are just debugger problems. I know I've seen the
second problem quite a few times (the debugger just seems to fail to
grab the right value for parameters in the function parameter list,
possibly due to optimizations?). And I believe the first problem can
also happen just because of the debugger (btw it's gdb 5.2.1 and gcc
3.2, it might be better nowadays).
Roland
btw if you haven't already seen it, Andreas report on ut2003/radeon
crash looks to me like it's a very related problem.
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64-0-0-7-branch...
Okay everything should be checked in and building, it doesn't work yet though :-) I'll hopefully get time over the next few days to hack on it again, I'm in the middle of moving apartments and work only pay me the odd hack to i810/radeon stuff, the mach64 is personal (as my laptop has it), if I get a monitor at some stage I might even get dual-head working!! Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa / DRI r200 crashes
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance in the old ut it'll always crash in the intro when the
announcer says in twenty-two ninety- segfault!)
gdb says this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4566)]
0x458bce72 in ?? ()
(gdb) bt
#0 0x458bce72 in ?? ()
#1 0x3cace852 in neutral_VertexAttrib2fvNV (index=9, v=0xa3812f4)
at vtxfmt_tmp.h:384
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at
api_arrayelt.c:828
#3 0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408,
start=29, count=34) at t_array_api.c:57
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6,
count=171564768) at t_array_api.c:153
This looks like something which Brian has been working on recently.
Roland, can you back up to _ae_loopback_array_elt() and 'print
*at-array'?
Certainly.
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print *at-array
$1 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa38104c ø\005\202?ø\005\202?, Enabled = 1,
Normalized = 0 '\0', BufferObj = 0xa39aae0, _MaxElement =
20, Flags = 1}
My guess is that the src pointer is invalid for some reason. The
pointer arithmetic looks OK though.
Basically, the glArrayElement() fallback code wasn't handling
glVertexAttrib arrays. I added that and expressed the
multi-texcoord arrays in terms of vertex attribs. Vertex attribute
9 corresponds to texcoord array 1.
In gdb, also check if at-array == ctx-Array.TexCoord[1].
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print at-array
$4 = (const struct gl_client_array *) 0xa3b2c38
(gdb) print ctx-Array.TexCoord[1]
Cannot access memory at address 0x14d89
(2 levels up)
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768)
at t_array_api.c:153
153 fallback_drawarrays( ctx, mode, start, start + count );
(gdb) print ctx-Array.TexCoord[1]
$5 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa381054 , Enabled = 1, Normalized = 0 '\0',
BufferObj = 0xa39aae0, _MaxElement = 20, Flags = 1}
Two things:
1. It's strange that ctx-Array.TexCoord[1] is an invalid address in
_ae_loopback_array_elt() but valid in _tnl_DrawArrays().
2. The count parameter to _tnl_DrawArrays() is _really_ large. What's
up with that?
I believe both problems are just debugger problems. I know I've seen the
second problem quite a few times (the debugger just seems to fail to
grab the right value for parameters in the function parameter list,
possibly due to optimizations?). And I believe the first problem can
also happen just because of the debugger (btw it's gdb 5.2.1 and gcc
3.2, it might be better nowadays).
Roland
btw if you haven't already seen it, Andreas report on ut2003/radeon
crash looks to me like it's a very related problem.
Try reverting api_arrayelt.c to version 1.18 and see what happens:
cvs update -r 1.18 api_arrayelt.c
-Brian
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
Am Dienstag, 10. Februar 2004 14:19 schrieb Roland Scheidegger: Dieter Nützel wrote: Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive: On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote: [ Following up to the dri-devel mailing list, we aren't really using the sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ] On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: I just ported the latest CVS drm-kernel code into the 2.6.2 vanilla kernel. Do you have a patch for us to look at? Yes, I think I posted it to the SourceForge bug tracker. It's down right now, or I'd be including a bug ID #. Does the same problem occur if you just build the DRM from DRI CVS? It won't compile. Aside from a small number of API changes, the Makefile.linux is *severely* broken about include directories under 2.6. I use only 2.6.x. There is No problem with DRI CVS (DRM). But some apps hang the graphics card (hard). UT2003 Citadel after some (= 3) seconds. But _very_ smooth with S3TC and Roland's hardware TCL patch. Some additional notes. It was your code (patch) with Mesa, GLX from last week. Not with latest Mesa and GLX code (Brian, Ian). It locks in Citadel during _first_ mouse move (immediately). I could move around not play Bombing Run (Egypt) for about 15 minutes. My girlfriend and I watched the GREAT textures mirrors and halls...;-) Now, with your patch r200_newlight-2.diff and latest (?) Mesa code the behavior is the same, but some textures (the mirrors, multi textures?) are broken in Bombing Run (Egypt). That's not good. There is nothing (both in the S3TC patch as well as in the changed lighting code) which could make lockups disappear. Using compressed textures shouldn't change anything (except the textures are smaller so less texture swapping is needed which might mean there are more free dma buffers available). The lighting changes did avoid some TCL fallback with materials between begin/end (and it looks like the fallback doesn't always work correctly, though I don't think it causes lockups), but in the latest patch (submitted to cvs yesterday) it's back in (as removing it wasn't correct and sometimes caused obvious rendering errors, it still awaits a proper fix). The patch still avoids a tcl fallback when using two-sided materials, but that really shouldn't have caused lockups... Maybe the broken textures? Meaning if the lockups have disappeared in UT2003, they are likely to reappear somewhere else. That said, I just tried to reproduce the lockups, but I can't even get ut2003 (demo 2206) to start here, it crashes even before the nvidia logo appears (seems to segfault and then be stuck waiting for a signal, killall -9 will just get rid of it fine). Now, it sigfault immediately like yours... /opt/Mesa ut2003_demo fcntl: Invalid argument fcntl: Invalid argument Mesa: software DXTn compression/decompression available Backtrace: [ 1] ./Core.so [0x40a0b78a] [ 2] /lib/i686/libpthread.so.0 [0x40dfd96c] [ 3] /lib/i686/libc.so.6 [0x40bc5aa8] Signal: SIGSEGV [segmentation fault] Aborting. Speicherschutzverletzung I can only hope it's not caused by the lighting changes I've commited yesterday (though I've no idea how these changes could cause that) - maybe some of the experimental code I've got here causes it. It must be something like that. -Dieter --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
Am Dienstag, 10. Februar 2004 14:19 schrieb Roland Scheidegger: Dieter Nützel wrote: Am Dienstag, 10. Februar 2004 08:45 schrieb Email Archive: On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote: [ Following up to the dri-devel mailing list, we aren't really using the sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ] On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: I just ported the latest CVS drm-kernel code into the 2.6.2 vanilla kernel. Do you have a patch for us to look at? Yes, I think I posted it to the SourceForge bug tracker. It's down right now, or I'd be including a bug ID #. Does the same problem occur if you just build the DRM from DRI CVS? It won't compile. Aside from a small number of API changes, the Makefile.linux is *severely* broken about include directories under 2.6. I use only 2.6.x. There is No problem with DRI CVS (DRM). But some apps hang the graphics card (hard). UT2003 Citadel after some (= 3) seconds. But _very_ smooth with S3TC and Roland's hardware TCL patch. Some additional notes. It was your code (patch) with Mesa, GLX from last week. Not with latest Mesa and GLX code (Brian, Ian). It locks in Citadel during _first_ mouse move (immediately). I could move around not play Bombing Run (Egypt) for about 15 minutes. My girlfriend and I watched the GREAT textures mirrors and halls...;-) Now, with your patch r200_newlight-2.diff and latest (?) Mesa code the behavior is the same, but some textures (the mirrors, multi textures?) are broken in Bombing Run (Egypt). That's not good. There is nothing (both in the S3TC patch as well as in the changed lighting code) which could make lockups disappear. Using compressed textures shouldn't change anything (except the textures are smaller so less texture swapping is needed which might mean there are more free dma buffers available). The lighting changes did avoid some TCL fallback with materials between begin/end (and it looks like the fallback doesn't always work correctly, though I don't think it causes lockups), but in the latest patch (submitted to cvs yesterday) it's back in (as removing it wasn't correct and sometimes caused obvious rendering errors, it still awaits a proper fix). The patch still avoids a tcl fallback when using two-sided materials, but that really shouldn't have caused lockups... Maybe the broken textures? Meaning if the lockups have disappeared in UT2003, they are likely to reappear somewhere else. That said, I just tried to reproduce the lockups, but I can't even get ut2003 (demo 2206) to start here, it crashes even before the nvidia logo appears (seems to segfault and then be stuck waiting for a signal, killall -9 will just get rid of it fine). Now, it sigfault immediately like yours... /opt/Mesa ut2003_demo fcntl: Invalid argument fcntl: Invalid argument Mesa: software DXTn compression/decompression available Backtrace: [ 1] ./Core.so [0x40a0b78a] [ 2] /lib/i686/libpthread.so.0 [0x40dfd96c] [ 3] /lib/i686/libc.so.6 [0x40bc5aa8] Signal: SIGSEGV [segmentation fault] Aborting. Speicherschutzverletzung I can only hope it's not caused by the lighting changes I've commited yesterday (though I've no idea how these changes could cause that) - maybe some of the experimental code I've got here causes it. It must be something like that. -Dieter --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa / DRI r200 crashes
Am Dienstag, 10. Februar 2004 23:35 schrieb Brian Paul:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance in the old ut it'll always crash in the intro when the
announcer says in twenty-two ninety- segfault!)
gdb says this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4566)]
0x458bce72 in ?? ()
(gdb) bt
#0 0x458bce72 in ?? ()
#1 0x3cace852 in neutral_VertexAttrib2fvNV (index=9, v=0xa3812f4)
at vtxfmt_tmp.h:384
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at
api_arrayelt.c:828
#3 0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408,
start=29, count=34) at t_array_api.c:57
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6,
count=171564768) at t_array_api.c:153
This looks like something which Brian has been working on recently.
Roland, can you back up to _ae_loopback_array_elt() and 'print
*at-array'?
Certainly.
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print *at-array
$1 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa38104c ø\005\202?ø\005\202?, Enabled = 1,
Normalized = 0 '\0', BufferObj = 0xa39aae0, _MaxElement =
20, Flags = 1}
My guess is that the src pointer is invalid for some reason. The
pointer arithmetic looks OK though.
Basically, the glArrayElement() fallback code wasn't handling
glVertexAttrib arrays. I added that and expressed the
multi-texcoord arrays in terms of vertex attribs. Vertex attribute
9 corresponds to texcoord array 1.
In gdb, also check if at-array == ctx-Array.TexCoord[1].
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print at-array
$4 = (const struct gl_client_array *) 0xa3b2c38
(gdb) print ctx-Array.TexCoord[1]
Cannot access memory at address 0x14d89
(2 levels up)
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768)
at t_array_api.c:153
153 fallback_drawarrays( ctx, mode, start, start + count );
(gdb) print ctx-Array.TexCoord[1]
$5 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa381054 , Enabled = 1, Normalized = 0 '\0',
BufferObj = 0xa39aae0, _MaxElement = 20, Flags = 1}
Two things:
1. It's strange that ctx-Array.TexCoord[1] is an invalid address in
_ae_loopback_array_elt() but valid in _tnl_DrawArrays().
2. The count parameter to _tnl_DrawArrays() is _really_ large. What's
up with that?
I believe both problems are just debugger problems. I know I've seen the
second problem quite a few times (the debugger just seems to fail to
grab the right value for parameters in the function parameter list,
possibly due to optimizations?). And I believe the first problem can
also happen just because of the debugger (btw it's gdb 5.2.1 and gcc
3.2, it might be better nowadays).
Roland
btw if you haven't already seen it, Andreas report on ut2003/radeon
crash looks to me like it's a very related problem.
Try reverting api_arrayelt.c to version 1.18 and see what happens:
cvs update -r 1.18 api_arrayelt.c
Have a look at my post
'Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps',
please.
Sorry, I got relay denied so I've postet twice.
Greetings,
Dieter
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa / DRI r200 crashes
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance in the old ut it'll always crash in the intro when the
announcer says in twenty-two ninety- segfault!)
gdb says this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4566)]
0x458bce72 in ?? ()
(gdb) bt
#0 0x458bce72 in ?? ()
#1 0x3cace852 in neutral_VertexAttrib2fvNV (index=9, v=0xa3812f4)
at vtxfmt_tmp.h:384
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at
api_arrayelt.c:828
#3 0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408,
start=29, count=34) at t_array_api.c:57
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6,
count=171564768) at t_array_api.c:153
This looks like something which Brian has been working on recently.
Roland, can you back up to _ae_loopback_array_elt() and 'print
*at-array'?
Certainly.
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print *at-array
$1 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa38104c ø\005\202?ø\005\202?, Enabled = 1,
Normalized = 0 '\0', BufferObj = 0xa39aae0, _MaxElement =
20, Flags = 1}
My guess is that the src pointer is invalid for some reason. The
pointer arithmetic looks OK though.
Basically, the glArrayElement() fallback code wasn't handling
glVertexAttrib arrays. I added that and expressed the
multi-texcoord arrays in terms of vertex attribs. Vertex attribute
9 corresponds to texcoord array 1.
In gdb, also check if at-array == ctx-Array.TexCoord[1].
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print at-array
$4 = (const struct gl_client_array *) 0xa3b2c38
(gdb) print ctx-Array.TexCoord[1]
Cannot access memory at address 0x14d89
(2 levels up)
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768)
at t_array_api.c:153
153 fallback_drawarrays( ctx, mode, start, start + count );
(gdb) print ctx-Array.TexCoord[1]
$5 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa381054 , Enabled = 1, Normalized = 0 '\0',
BufferObj = 0xa39aae0, _MaxElement = 20, Flags = 1}
Two things:
1. It's strange that ctx-Array.TexCoord[1] is an invalid address in
_ae_loopback_array_elt() but valid in _tnl_DrawArrays().
2. The count parameter to _tnl_DrawArrays() is _really_ large. What's
up with that?
I believe both problems are just debugger problems. I know I've seen the
second problem quite a few times (the debugger just seems to fail to
grab the right value for parameters in the function parameter list,
possibly due to optimizations?). And I believe the first problem can
also happen just because of the debugger (btw it's gdb 5.2.1 and gcc
3.2, it might be better nowadays).
If you compile without -O2 (edit host.def), these problems should go away.
Keith
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa / DRI r200 crashes
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very recently
in the tnl code? The crashes sometimes are predictable (for
instance in the old ut it'll always crash in the intro when the
announcer says in twenty-two ninety- segfault!)
gdb says this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4566)]
0x458bce72 in ?? ()
(gdb) bt
#0 0x458bce72 in ?? ()
#1 0x3cace852 in neutral_VertexAttrib2fvNV (index=9,
v=0xa3812f4) at vtxfmt_tmp.h:384
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at
api_arrayelt.c:828
#3 0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408,
start=29, count=34) at t_array_api.c:57
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6,
count=171564768) at t_array_api.c:153
This looks like something which Brian has been working on recently.
Roland, can you back up to _ae_loopback_array_elt() and 'print
*at-array'?
Certainly.
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print *at-array
$1 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa38104c ø\005\202?ø\005\202?, Enabled = 1,
Normalized = 0 '\0', BufferObj = 0xa39aae0, _MaxElement =
20, Flags = 1}
My guess is that the src pointer is invalid for some reason. The
pointer arithmetic looks OK though.
Basically, the glArrayElement() fallback code wasn't handling
glVertexAttrib arrays. I added that and expressed the
multi-texcoord arrays in terms of vertex attribs. Vertex attribute
9 corresponds to texcoord array 1.
In gdb, also check if at-array == ctx-Array.TexCoord[1].
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print at-array
$4 = (const struct gl_client_array *) 0xa3b2c38
(gdb) print ctx-Array.TexCoord[1]
Cannot access memory at address 0x14d89
(2 levels up)
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6, count=171564768)
at t_array_api.c:153
153 fallback_drawarrays( ctx, mode, start, start + count );
(gdb) print ctx-Array.TexCoord[1]
$5 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa381054 , Enabled = 1, Normalized = 0 '\0',
BufferObj = 0xa39aae0, _MaxElement = 20, Flags = 1}
Two things:
1. It's strange that ctx-Array.TexCoord[1] is an invalid address in
_ae_loopback_array_elt() but valid in _tnl_DrawArrays().
2. The count parameter to _tnl_DrawArrays() is _really_ large.
What's up with that?
I believe both problems are just debugger problems. I know I've seen
the second problem quite a few times (the debugger just seems to fail
to grab the right value for parameters in the function parameter list,
possibly due to optimizations?). And I believe the first problem can
also happen just because of the debugger (btw it's gdb 5.2.1 and gcc
3.2, it might be better nowadays).
Roland
btw if you haven't already seen it, Andreas report on ut2003/radeon
crash looks to me like it's a very related problem.
Try reverting api_arrayelt.c to version 1.18 and see what happens:
cvs update -r 1.18 api_arrayelt.c
This indeed fixes the crash in both the ut intro and ut2003 startup.
Roland
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRM+ATI-Radeon-Mobility
Using the radeon.o driver from 2.4.22 with 2.4.24 avoids the problem. Looking at the diffs between the radeon code in 22 and 24 I see: + some new CP microcode + changes to the initialization of the scratch register pointer + changes to the radeon_do_init_pageflip method + changes to the radeon_freelist_int method that notes a potential deadlock! + lots and lots and lots of other changes. So I think there are plenty of good candidates for this problem. I guess the next step is to check with 2.4.23 to see if I can narrow down to a smaller change set (but I don't think there were many changes from 23 to 24?). Unfortunately I am moving house this week, so I'm not going to have much more of a chance to debug this.But if somebody has some test code they want to try, I'm happy to find time to give it a go. cheers Michel Dnzer wrote: On Tue, 2004-02-10 at 13:36, Greg Wilkins wrote: I can confirm that doing a warm reboot from 4.2.22 to 4.2.24 solves the problem and that glxgears works. Some random ideas to try and further track down the problem: * make a diff of drivers/char/drm between kernels 2.4.22 and 2.4.24, and check it for obvious regressions on hardware initialisation * move the contents of drivers/char/drm from kernel 2.4.22 to 2.4.24 and/or vice versa, and see if it still works/breaks --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa / DRI r200 crashes
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very
recently in the tnl code? The crashes sometimes are predictable
(for instance in the old ut it'll always crash in the intro when
the announcer says in twenty-two ninety- segfault!)
gdb says this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4566)]
0x458bce72 in ?? ()
(gdb) bt
#0 0x458bce72 in ?? ()
#1 0x3cace852 in neutral_VertexAttrib2fvNV (index=9,
v=0xa3812f4) at vtxfmt_tmp.h:384
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at
api_arrayelt.c:828
#3 0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408,
start=29, count=34) at t_array_api.c:57
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6,
count=171564768) at t_array_api.c:153
This looks like something which Brian has been working on recently.
Roland, can you back up to _ae_loopback_array_elt() and 'print
*at-array'?
Certainly.
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at
api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print *at-array
$1 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa38104c ø\005\202?ø\005\202?, Enabled = 1,
Normalized = 0 '\0', BufferObj = 0xa39aae0, _MaxElement =
20, Flags = 1}
My guess is that the src pointer is invalid for some reason. The
pointer arithmetic looks OK though.
Basically, the glArrayElement() fallback code wasn't handling
glVertexAttrib arrays. I added that and expressed the
multi-texcoord arrays in terms of vertex attribs. Vertex
attribute 9 corresponds to texcoord array 1.
In gdb, also check if at-array == ctx-Array.TexCoord[1].
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at
api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print at-array
$4 = (const struct gl_client_array *) 0xa3b2c38
(gdb) print ctx-Array.TexCoord[1]
Cannot access memory at address 0x14d89
(2 levels up)
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6,
count=171564768) at t_array_api.c:153
153 fallback_drawarrays( ctx, mode, start, start + count );
(gdb) print ctx-Array.TexCoord[1]
$5 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa381054 , Enabled = 1, Normalized = 0 '\0',
BufferObj = 0xa39aae0, _MaxElement = 20, Flags = 1}
Two things:
1. It's strange that ctx-Array.TexCoord[1] is an invalid address in
_ae_loopback_array_elt() but valid in _tnl_DrawArrays().
2. The count parameter to _tnl_DrawArrays() is _really_ large.
What's up with that?
I believe both problems are just debugger problems. I know I've seen
the second problem quite a few times (the debugger just seems to fail
to grab the right value for parameters in the function parameter
list, possibly due to optimizations?). And I believe the first
problem can also happen just because of the debugger (btw it's gdb
5.2.1 and gcc 3.2, it might be better nowadays).
Roland
btw if you haven't already seen it, Andreas report on ut2003/radeon
crash looks to me like it's a very related problem.
Try reverting api_arrayelt.c to version 1.18 and see what happens:
cvs update -r 1.18 api_arrayelt.c
This indeed fixes the crash in both the ut intro and ut2003 startup.
OK, perhaps you could check in the restored version for now. I may
not get to look into this further for a day or two.
-Brian
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa / DRI r200 crashes
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
I get a lot of dri crashes, were there some changes very
recently in the tnl code? The crashes sometimes are predictable
(for instance in the old ut it'll always crash in the intro
when the announcer says in twenty-two ninety- segfault!)
gdb says this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4566)]
0x458bce72 in ?? ()
(gdb) bt
#0 0x458bce72 in ?? ()
#1 0x3cace852 in neutral_VertexAttrib2fvNV (index=9,
v=0xa3812f4) at vtxfmt_tmp.h:384
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at
api_arrayelt.c:828
#3 0x3cb2be5a in fallback_drawarrays (ctx=0x9, mode=171750408,
start=29, count=34) at t_array_api.c:57
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6,
count=171564768) at t_array_api.c:153
This looks like something which Brian has been working on recently.
Roland, can you back up to _ae_loopback_array_elt() and 'print
*at-array'?
Certainly.
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at
api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print *at-array
$1 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa38104c ø\005\202?ø\005\202?, Enabled = 1,
Normalized = 0 '\0', BufferObj = 0xa39aae0, _MaxElement =
20, Flags = 1}
My guess is that the src pointer is invalid for some reason. The
pointer arithmetic looks OK though.
Basically, the glArrayElement() fallback code wasn't handling
glVertexAttrib arrays. I added that and expressed the
multi-texcoord arrays in terms of vertex attribs. Vertex
attribute 9 corresponds to texcoord array 1.
In gdb, also check if at-array == ctx-Array.TexCoord[1].
#2 0x3ca40c41 in _ae_loopback_array_elt (elt=28) at
api_arrayelt.c:828
828 at-func( at-index, src );
(gdb) print at-array
$4 = (const struct gl_client_array *) 0xa3b2c38
(gdb) print ctx-Array.TexCoord[1]
Cannot access memory at address 0x14d89
(2 levels up)
#4 0x3cb2c36d in _tnl_DrawArrays (mode=6, start=6,
count=171564768) at t_array_api.c:153
153 fallback_drawarrays( ctx, mode, start, start + count );
(gdb) print ctx-Array.TexCoord[1]
$5 = {Size = 2, Type = 5126, Stride = 24, StrideB = 24, Ptr =
0xa381054 , Enabled = 1, Normalized = 0 '\0',
BufferObj = 0xa39aae0, _MaxElement = 20, Flags = 1}
Two things:
1. It's strange that ctx-Array.TexCoord[1] is an invalid address
in _ae_loopback_array_elt() but valid in _tnl_DrawArrays().
2. The count parameter to _tnl_DrawArrays() is _really_ large.
What's up with that?
I believe both problems are just debugger problems. I know I've seen
the second problem quite a few times (the debugger just seems to
fail to grab the right value for parameters in the function
parameter list, possibly due to optimizations?). And I believe the
first problem can also happen just because of the debugger (btw it's
gdb 5.2.1 and gcc 3.2, it might be better nowadays).
Roland
btw if you haven't already seen it, Andreas report on ut2003/radeon
crash looks to me like it's a very related problem.
Try reverting api_arrayelt.c to version 1.18 and see what happens:
cvs update -r 1.18 api_arrayelt.c
This indeed fixes the crash in both the ut intro and ut2003 startup.
OK, perhaps you could check in the restored version for now. I may not
get to look into this further for a day or two.
-Brian
Oh - such a drastic measure :-(. Is there some way to revert changes in
cvs, or do I just have to submit that as a new version, maybe even with
tricks like update it (with -r), then locally remove the revision tag in
the CVS Entries file and commit it? I don't want to hose the cvs
repository...
Roland
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] New DRI driver interface (Re: CVS Update: xc (branch: driinterface-0-0-3-branch))
Ian Romanick wrote: Log message: Incorporate all changes from the driinterface-0-0-2-branch. Obtained from: driinterface-0-0-2-branch In the past I have had a DRI / non-DRI time split of 90%/10%. As of last Monday that switched to 10%/90%. This has caused me to change some of the DRI related plans. Here are my intentions for the short-term future. 1. Commit some minor changes to the r200 driver to use the new interfaces. This will go in Mesa trunk, but will be guarded by #ifdef. This is needed because the code calls some functions in dri_util.c that only exist in the branch. 2. Finish adding at least rudimentary server-side fbconfig support to the 0-0-3 branch. Looking at my 0-0-2 tree, which I haven't touched since November, it looks like most of the work has actually been done. That should allow us to enable GLX_SGIX_fbconfig in any driver that uses the new interfaces (i.e., r200 initially). 3. After some testing and cool down period, merge the branch into the trunk. I expect this to happen fairly quickly. 4. Create a driinterface-0-0-4-branch. The purpose of this branch will be to implement GLX protocol and indirect rendering support for pbuffers. *LOTS* of work will need to be done to the driver to enable pbuffers, so that won't be part of this branch. Once this is done, the client library and server will be able to advertise GLX 1.3 (for indirect rendering anyway). If someone can add protocol support for ARB_texture_compression, we can actually advertise support for GLX 1.4. Since there is already protocol support for the new functionality in GL 1.4, we may even be able to advertise GLX 1.5, but I'm not 100% sure about that. There's no official spec for either GLX 1.4 or GLX 1.5. :( 5. After some testing and cool down period, merge the branch into the trunk. I expect this to happen fairly quickly. At that point, I probably won't be able to do very much big. The big things that will need to be done at that point are: 1. Enable GLX_SGI_make_current_read support in all drivers. The MGA driver already supports this extension. I did a patch once, which I'll have to find, that enabled it for r200, but the patch only worked with pageflipping disabled. People can start working on this now, if they like. :) 2. Port all drivers to the new interfaces. My intention is for the new interfaces to be the *only* interfaces in XFree86 5.0.0 (whenever that happens). They should also be the only interfaces for stand-alone drivers. This can start as soon as I commit my changes to the r200 driver. 3. Pave the way for pbuffer support in the drivers. Work may need to be done to support odd back/front/depth buffer combinations that will happen with pbuffers. Ideally we should be able to support things like pbuffers with 32-bit color and 16-bit depth (or vice-versa), etc. Once the pbuffer protocol is in, real pbuffer support can be done. I think the easiest way to do this will be to reserver a portion of off screen memory for pbuffers. Apps will allocate memory from this and use it for their pbuffer. 4. Change the interface between libglx.a and libGLcore.a to be the same as the interface between libGL.so and *_dri.so. This is *BIG*, but important. I will start doing some of this with the server-side work that I'm doing, but it's way more project than I have time to tackle. The ultimate goal of this is, of course, to get server-side accelerated 3D. I don't really expect much of this to be done until after the dust settles from the other changes. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa / DRI r200 crashes
OK, perhaps you could check in the restored version for now. I may not get to look into this further for a day or two. -Brian Oh - such a drastic measure :-(. Is there some way to revert changes in cvs, or do I just have to submit that as a new version, maybe even with tricks like update it (with -r), then locally remove the revision tag in the CVS Entries file and commit it? I don't want to hose the cvs repository... Sorry, nevermind. I think I've figured it out. Roland --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 1169] DRI works on X initiation, but fails later
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=1169 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-02-10 21:32 --- *** Bug 1170 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRM+ATI-Radeon-Mobility
The problem identified by DRM+ATI-Radeon-Mobility appeared already with kernel 2.4.23-pre8 Freezing takes place when function, gl_init_all_x86_transform_asm called from /usr/X11R6/lib/modules/dri/radeon_dri.so is to be executed (see eg., gdb tunnel ) Regards Wlodek --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 1169] DRI works on X initiation, but fails later
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=1169 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-02-10 21:06 --- DRI -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: GATOS and DRI merge
On Tue, 10 Feb 2004, Hod McWuff wrote: So, to summarize, I need to know *roughly* what's changed since the Gatos folks forked, in terms of what-moved-where and an idea of any structural changes. I can read the different sources and figure out the code changes myself, but I need to know what I'm looking for. Presumeably the best way to find out what the GATOS developer(s) changed, would be to ask them. ;o) It would seem the best approach is to merge their changes - conceptually, one by one - into the current DRI sources. That sounds sane, however some of it may require a bit of discussion to iron out issues. For example, anything that might break ABI would be a no-go. If I recall correctly, in the past there were ABI changing differences, however I have no idea if that is the case nowadays. That said, it would indeed be nice to have GATOS efforts work out of the box with one single unified driver set. -- Mike A. Harris --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote: [ Following up to the dri-devel mailing list, we aren't really using the sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ] On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: I just ported the latest CVS drm-kernel code into the 2.6.2 vanilla kernel. Do you have a patch for us to look at? Yes, I think I posted it to the SourceForge bug tracker. It's down right now, or I'd be including a bug ID #. Does the same problem occur if you just build the DRM from DRI CVS? It won't compile. Aside from a small number of API changes, the Makefile.linux is *severely* broken about include directories under 2.6. Many apps work fine - xscreensaver, prboom, SpectrumGL, but some others lock the X server up hard, such as tuxracer and BillardGL. Are you using the 3D driver built from DRI and Mesa CVS, or an older version? I'm using gentoo's xfree-4.3.0-r3, and I've tried both their ati-gatos package and a manual install from the latest ati.2 cvs sources. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
On Tue, 2004-02-10 at 08:45, Email Archive wrote: On Mon, 2004-02-09 at 20:55, Michel Dnzer wrote: [ Following up to the dri-devel mailing list, we aren't really using the sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ] On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: I just ported the latest CVS drm-kernel code into the 2.6.2 vanilla kernel. Do you have a patch for us to look at? Yes, I think I posted it to the SourceForge bug tracker. It's down right now, or I'd be including a bug ID #. You mean the one in the subject? :) I've looked at the patch briefly. First of all, I find unified diffs much easier to read than context diffs. Then, I don't understand what exactly the patch was made against. Can hardly be against the 2.6.2 kernel, and at least the AGP related changes have been in DRI CVS for a while... Does the same problem occur if you just build the DRM from DRI CVS? It won't compile. Aside from a small number of API changes, the Makefile.linux is *severely* broken about include directories under 2.6. Works perfectly here... Do you have current DRI CVS from freedesktop.org? If so, please post the errors. Many apps work fine - xscreensaver, prboom, SpectrumGL, but some others lock the X server up hard, such as tuxracer and BillardGL. Are you using the 3D driver built from DRI and Mesa CVS, or an older version? I'm using gentoo's xfree-4.3.0-r3, and I've tried both their ati-gatos package and a manual install from the latest ati.2 cvs sources. No lockups with tuxracer or BillardGL running the DRM from current DRI CVS on 2.6.2 (nor the one that ships with the kernel) here. You may want to try a newer 3D driver. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
On Tue, 2004-02-10 at 17:46, Hod McWuff wrote: On Tue, 2004-02-10 at 10:17, Michel Dnzer wrote: On Tue, 2004-02-10 at 08:45, Email Archive wrote: On Mon, 2004-02-09 at 20:55, Michel Dnzer wrote: On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: [...] I don't understand what exactly the patch was made against. [...] It was against a checkout of drm-kernel, [...] I was going to ask what's drm-kernel?, but it cleared up below... Does the same problem occur if you just build the DRM from DRI CVS? It won't compile. Aside from a small number of API changes, the Makefile.linux is *severely* broken about include directories under 2.6. Works perfectly here... Do you have current DRI CVS from freedesktop.org? If so, please post the errors. from freedesktop.org? not from sourceforge anymore? :pserver:[EMAIL PROTECTED]:/cvsroot/gatos ^ ^ gatos != dri DRI CVS has moved to freedesktop.org. Many apps work fine - xscreensaver, prboom, SpectrumGL, but some others lock the X server up hard, such as tuxracer and BillardGL. Are you using the 3D driver built from DRI and Mesa CVS, or an older version? I'm using gentoo's xfree-4.3.0-r3, and I've tried both their ati-gatos package and a manual install from the latest ati.2 cvs sources. No lockups with tuxracer or BillardGL running the DRM from current DRI CVS on 2.6.2 (nor the one that ships with the kernel) here. You may want to try a newer 3D driver. The one that ships with the kernel won't fly due to version number - if memory serves it did before installing ati.2, but seeing how the machine (with its AIW Radeon) serves as my living room entertainment center, having A/V capability trumped 3D. The Radeon DRM and 3D drivers from the GATOS project are incompatible to those from the DRI project. Unfortunately, GATOS didn't reflect this incompatibility correctly in their DRM version, otherwise the wrong 3D driver would refuse to run instead of locking up the machine. Fortunately, the root cause of the incompatibility has been removed in DRI CVS, GATOS just needs to adapt to that. It's beginning to look like my entire problem might be having missed a move of the CVS source hosting. You simply seem to have missed that GATOS and DRI are different projects. :) -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
On Tue, 2004-02-10 at 10:17, Michel Dänzer wrote: On Tue, 2004-02-10 at 08:45, Email Archive wrote: On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote: [ Following up to the dri-devel mailing list, we aren't really using the sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ] On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: I just ported the latest CVS drm-kernel code into the 2.6.2 vanilla kernel. Do you have a patch for us to look at? Yes, I think I posted it to the SourceForge bug tracker. It's down right now, or I'd be including a bug ID #. You mean the one in the subject? :) Rght... that's what I get for staying up so late ;) I've looked at the patch briefly. First of all, I find unified diffs much easier to read than context diffs. Then, I don't understand what exactly the patch was made against. Can hardly be against the 2.6.2 kernel, and at least the AGP related changes have been in DRI CVS for a while... It was against a checkout of drm-kernel, and then manually copy the .c and .h files into the 2.6.2 tree. Does the same problem occur if you just build the DRM from DRI CVS? It won't compile. Aside from a small number of API changes, the Makefile.linux is *severely* broken about include directories under 2.6. Works perfectly here... Do you have current DRI CVS from freedesktop.org? If so, please post the errors. from freedesktop.org? not from sourceforge anymore? :pserver:[EMAIL PROTECTED]:/cvsroot/gatos Many apps work fine - xscreensaver, prboom, SpectrumGL, but some others lock the X server up hard, such as tuxracer and BillardGL. Are you using the 3D driver built from DRI and Mesa CVS, or an older version? I'm using gentoo's xfree-4.3.0-r3, and I've tried both their ati-gatos package and a manual install from the latest ati.2 cvs sources. No lockups with tuxracer or BillardGL running the DRM from current DRI CVS on 2.6.2 (nor the one that ships with the kernel) here. You may want to try a newer 3D driver. The one that ships with the kernel won't fly due to version number - if memory serves it did before installing ati.2, but seeing how the machine (with its AIW Radeon) serves as my living room entertainment center, having A/V capability trumped 3D. ati.2 CVSROOT: :pserver:[EMAIL PROTECTED]:/cvsroot/gatos It's beginning to look like my entire problem might be having missed a move of the CVS source hosting. Let me see what turns up... if that is the case, I'd suggest modifying the Makefiles on the sf.net copy to cause an error message if anyone tries compiling them. While we're on the subject, what's the status of integration with the XFree 4.4 betas? Would I be better off going that way? OK, I just checked out the new xc tree... seems to be some confusion going on between it and the documentation about having the Mesa tree. Hrm? Thanks, - Hod McWuff --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
OK, I managed to compile just the kernel portion from what I hope is the new CVS tree (:pserver:[EMAIL PROTECTED]:/cvs/dri) I get this in the X server output, which is also about what I expect to see from the ones in the kernel: (EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. [dri] radeon.o kernel module version is 1.10.0 but version 1.100.0 or newer is needed. [dri] Disabling DRI. On Tue, 2004-02-10 at 10:17, Michel Dänzer wrote: On Tue, 2004-02-10 at 08:45, Email Archive wrote: On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote: [ Following up to the dri-devel mailing list, we aren't really using the sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ] On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: I just ported the latest CVS drm-kernel code into the 2.6.2 vanilla kernel. Do you have a patch for us to look at? Yes, I think I posted it to the SourceForge bug tracker. It's down right now, or I'd be including a bug ID #. You mean the one in the subject? :) I've looked at the patch briefly. First of all, I find unified diffs much easier to read than context diffs. Then, I don't understand what exactly the patch was made against. Can hardly be against the 2.6.2 kernel, and at least the AGP related changes have been in DRI CVS for a while... Does the same problem occur if you just build the DRM from DRI CVS? It won't compile. Aside from a small number of API changes, the Makefile.linux is *severely* broken about include directories under 2.6. Works perfectly here... Do you have current DRI CVS from freedesktop.org? If so, please post the errors. Many apps work fine - xscreensaver, prboom, SpectrumGL, but some others lock the X server up hard, such as tuxracer and BillardGL. Are you using the 3D driver built from DRI and Mesa CVS, or an older version? I'm using gentoo's xfree-4.3.0-r3, and I've tried both their ati-gatos package and a manual install from the latest ati.2 cvs sources. No lockups with tuxracer or BillardGL running the DRM from current DRI CVS on 2.6.2 (nor the one that ships with the kernel) here. You may want to try a newer 3D driver. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
The Radeon DRM and 3D drivers from the GATOS project are incompatible to those from the DRI project. Unfortunately, GATOS didn't reflect this incompatibility correctly in their DRM version, otherwise the wrong 3D driver would refuse to run instead of locking up the machine. Fortunately, the root cause of the incompatibility has been removed in DRI CVS, GATOS just needs to adapt to that. OK, well I haven't seen a whole lot of activity from the Gatos folks in quite a while... what's that incompatibility you speak of? I might try my hand at removing it. Obviously I'd rather just have to merge the kernel modules, but if I have to dig into the XFree side then so be it... AIW Radeon can't properly be said to be supported until Gatos and DRI are playing nice together again. It's beginning to look like my entire problem might be having missed a move of the CVS source hosting. You simply seem to have missed that GATOS and DRI are different projects. :) Right... which seems like one hell of a thinko to me... *thwaps self* -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
Now I've changed the version number in the xc/bleh kernel module. I'm not getting hard server locks anymore, but now *all* GL apps show an empty black window that never changes. Something is definitely still funky. I'm guessing this has something to do with the ati.2 module I've got installed. Is a manual code merge between the ati.2-compatible old version and the new cvs trunk required? (follow up to:) OK, I managed to compile just the kernel portion from what I hope is the new CVS tree (:pserver:[EMAIL PROTECTED]:/cvs/dri) I get this in the X server output, which is also about what I expect to see from the ones in the kernel: (EE) RADEON(0): [dri] RADEONDRIScreenInit failed because of a version mismatch. [dri] radeon.o kernel module version is 1.10.0 but version 1.100.0 or newer is needed. [dri] Disabling DRI. On Tue, 2004-02-10 at 11:46, Hod McWuff wrote: On Tue, 2004-02-10 at 10:17, Michel Dänzer wrote: On Tue, 2004-02-10 at 08:45, Email Archive wrote: On Mon, 2004-02-09 at 20:55, Michel Dänzer wrote: [ Following up to the dri-devel mailing list, we aren't really using the sf.net bug tracker anymore but rather the kernel and XFree86 bugzillas ] On Mon, 2004-02-09 at 04:55, SourceForge.net wrote: I just ported the latest CVS drm-kernel code into the 2.6.2 vanilla kernel. Do you have a patch for us to look at? Yes, I think I posted it to the SourceForge bug tracker. It's down right now, or I'd be including a bug ID #. You mean the one in the subject? :) Rght... that's what I get for staying up so late ;) I've looked at the patch briefly. First of all, I find unified diffs much easier to read than context diffs. Then, I don't understand what exactly the patch was made against. Can hardly be against the 2.6.2 kernel, and at least the AGP related changes have been in DRI CVS for a while... It was against a checkout of drm-kernel, and then manually copy the .c and .h files into the 2.6.2 tree. Does the same problem occur if you just build the DRM from DRI CVS? It won't compile. Aside from a small number of API changes, the Makefile.linux is *severely* broken about include directories under 2.6. Works perfectly here... Do you have current DRI CVS from freedesktop.org? If so, please post the errors. from freedesktop.org? not from sourceforge anymore? :pserver:[EMAIL PROTECTED]:/cvsroot/gatos Many apps work fine - xscreensaver, prboom, SpectrumGL, but some others lock the X server up hard, such as tuxracer and BillardGL. Are you using the 3D driver built from DRI and Mesa CVS, or an older version? I'm using gentoo's xfree-4.3.0-r3, and I've tried both their ati-gatos package and a manual install from the latest ati.2 cvs sources. No lockups with tuxracer or BillardGL running the DRM from current DRI CVS on 2.6.2 (nor the one that ships with the kernel) here. You may want to try a newer 3D driver. The one that ships with the kernel won't fly due to version number - if memory serves it did before installing ati.2, but seeing how the machine (with its AIW Radeon) serves as my living room entertainment center, having A/V capability trumped 3D. ati.2 CVSROOT: :pserver:[EMAIL PROTECTED]:/cvsroot/gatos It's beginning to look like my entire problem might be having missed a move of the CVS source hosting. Let me see what turns up... if that is the case, I'd suggest modifying the Makefiles on the sf.net copy to cause an error message if anyone tries compiling them. While we're on the subject, what's the status of integration with the XFree 4.4 betas? Would I be better off going that way? OK, I just checked out the new xc tree... seems to be some confusion going on between it and the documentation about having the Mesa tree. Hrm? Thanks, - Hod McWuff --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [ dri-Bugs-893194 ] Radeon locks up with complex GL apps
On Tue, 2004-02-10 at 18:33, Hod McWuff wrote:
Fortunately, the root cause of the incompatibility has been removed in
DRI CVS, GATOS just needs to adapt to that.
OK, well I haven't seen a whole lot of activity from the Gatos folks in
quite a while... what's that incompatibility you speak of? I might try my
hand at removing it.
The locations of the framebuffer and GART apertures
(MC_{FB,AGP}_LOCATION registers) used to be hardcoded to different
places in the card's address space. Look at RADEONSetFBLocation() in
radeon_driver.c, GATOS needs to do mostly the same, possibly with some
modifications (I don't know if video capturing requires direct rendering
to be enabled, for example).
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] GATOS and DRI merge
OK, onward and upward... I'm starting to investigate what it would take to merge the GATOS functionality into the current DRI. I'm sure the XFree side is going to be a pain in the ass, but I'm starting with the kernel modules. The first discrepancy I need cleared up is about driver support. The current DRI source seems to have drivers for: i810,i830,mga,r128,radeon,sis,tdfx Some are split between multiple files, some are in a single file. If there's a document somewhere saying what files have what, then it'd help to see it. The kernel copy also has a 'ffb' driver, which I'm assuming until someone tells me otherwise is an out of date hack. The Gatos copy has the same drivers as the DRI source, but all split amongst many files. I have a feeling the gamma and SIS drivers in this copy are screwed totally anyway - in fact probably only the radeon and r128 drivers from Gatos are relevant anyway, plus any changes in the drm_* files. So, to summarize, I need to know *roughly* what's changed since the Gatos folks forked, in terms of what-moved-where and an idea of any structural changes. I can read the different sources and figure out the code changes myself, but I need to know what I'm looking for. It would seem the best approach is to merge their changes - conceptually, one by one - into the current DRI sources. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GATOS and DRI merge
Did GATOS make changes to the DRM drivers? Is it using I2C to get to the TV tuner on ATI cards? What else get changed in the Xfree drivers? --- Hod McWuff [EMAIL PROTECTED] wrote: OK, onward and upward... I'm starting to investigate what it would take to merge the GATOS functionality into the current DRI. I'm sure the XFree side is going to be a pain in the ass, but I'm starting with the kernel modules. The first discrepancy I need cleared up is about driver support. The current DRI source seems to have drivers for: i810,i830,mga,r128,radeon,sis,tdfx Some are split between multiple files, some are in a single file. If there's a document somewhere saying what files have what, then it'd help to see it. The kernel copy also has a 'ffb' driver, which I'm assuming until someone tells me otherwise is an out of date hack. The Gatos copy has the same drivers as the DRI source, but all split amongst many files. I have a feeling the gamma and SIS drivers in this copy are screwed totally anyway - in fact probably only the radeon and r128 drivers from Gatos are relevant anyway, plus any changes in the drm_* files. So, to summarize, I need to know *roughly* what's changed since the Gatos folks forked, in terms of what-moved-where and an idea of any structural changes. I can read the different sources and figure out the code changes myself, but I need to know what I'm looking for. It would seem the best approach is to merge their changes - conceptually, one by one - into the current DRI sources. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Fwd: [Dri-users] glPushAttrib()
I'm forwarding this to the devel list. Alex __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html---BeginMessage--- Hi all, Recently I've discovered (after some hours of debugging) that there's a problem with glPushAttrib() which has some unexpected behaviour. Someone probably reported the bug before, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=180157 I suspect the problem is DRI specific because I also have a nVidia chip (with nvidia Linux drivers) and the same code behaves as it should. The problem has been encountered in two ATI cards: Radeon Mobility M6 LY (iBook 2.2) and Radeon 8500 (PC). I was wondering, then, what to do: send a bug-report or, if someone already did or it's just fixed in current version, wait for the Debian package (btw, I use Michel Dänzer's *-dri-trunk Debian packages). Any ideas? Thanks in advance. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-users---End Message---
Re: [Dri-devel] GATOS and DRI merge
There are two mainpieces to this that I know of, maybe more.
1) The tuner
2) video overlays
xserver may render video overlays pointless. Once we get hardware compositing
going you should be able to rebuild the entire screen on every TV frame. You may
want to review what is happening with xserver before spending a lot of time on
overlays. How does this play with the current state of XV?
Don't the All-in-wonder boards use the bt8x8 tuner chips? Any idea why the BT
driver in drivers/media/video won't work for the ATI cards? I have the docs for
the AIW but they're in RTF, I'm downloading OpenOffice right now. It might be
easier to just fix the existing BT driver to work on the ATI cards.
I see also that there are drivers for the remote control and TV output. TV out
probably has to be intergrated into the X driver. Remote control should work
standalone.
--- Hod McWuff [EMAIL PROTECTED] wrote:
On Tue, 2004-02-10 at 17:44, Jon Smirl wrote:
Did GATOS make changes to the DRM drivers?
Yes, for a while I was tracking its CVS and rebuilding often. I had
3D and video working together just fine under 2.4. Gentoo Linux even
went as far as making a drm-kernel ebuild that patched for gatos.
:pserver:[EMAIL PROTECTED]:/cvsroot/gatos
module drm-kernel
Is it using I2C to get to the TV tuner on ATI cards?
No. I2C, so far as I know, isn't involved at all.
What else get changed in the Xfree drivers?
They have an ati.2 module (same CVSROOT) that you xmkmf against a
compiled XFree tree, then make ; make install, that provides access to
the tuner and v4l playback (MPEG acceleration). A separate kernel module
is required for video capture.
The ati.2 module replaces
/usr/X11R6/lib/modules/drivers/{ati,atimisc,r128,radeon}_drv.o
and adds
/usr/X11R6/lib/modules/multimedia/{bt829,fil236,msp3430,saa7114,tda8425,tda9850,tda9886,theatre}_drv.o
--- Hod McWuff [EMAIL PROTECTED] wrote:
OK, onward and upward... I'm starting to investigate what it would take
to merge the GATOS functionality into the current DRI. I'm sure the
XFree side is going to be a pain in the ass, but I'm starting with the
kernel modules.
The first discrepancy I need cleared up is about driver support. The
current DRI source seems to have drivers for:
i810,i830,mga,r128,radeon,sis,tdfx
Some are split between multiple files, some are in a single file.
If there's a document somewhere saying what files have what, then it'd
help to see it.
The kernel copy also has a 'ffb' driver, which I'm assuming until
someone tells me otherwise is an out of date hack.
The Gatos copy has the same drivers as the DRI source, but all split
amongst many files. I have a feeling the gamma and SIS drivers in this
copy are screwed totally anyway - in fact probably only the radeon and
r128 drivers from Gatos are relevant anyway, plus any changes in the
drm_* files.
So, to summarize, I need to know *roughly* what's changed since the
Gatos folks forked, in terms of what-moved-where and an idea of any
structural changes. I can read the different sources and figure out the
code changes myself, but I need to know what I'm looking for.
It would seem the best approach is to merge their changes -
conceptually, one by one - into the current DRI sources.
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
