[Dri-devel] Re: r200 texture problems
On Sat, 2004-01-24 at 15:28, Keith Whitwell wrote: Michel Dnzer wrote: On Fri, 2004-01-23 at 03:45, Michel Dnzer wrote: On Fri, 2004-01-23 at 02:28, Michel Dnzer wrote: [...] most if not all textured apps spew [driAllocateTexture:577] unable to allocate texture all over the place and seem to fall back to software rendering. In contrast to the other problem, this doesn't occur on R100. Reverting Ian's commit from Wednesday doesn't help. But reverting Mesa/src/mesa/drivers/dri/common/texmem.c to revision 1.3 does. Keith, any idea what's up there? I've lost the beginning of this thread - That's fine, this problem isn't related to that. :) how should I reproduce the problem? Start any textured app (e.g. the xscreensaver lament hack) with current libGL from DRI CVS and current r200 driver from Mesa CVS. -- 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] Re: libGL backwards compatibility broken
On Fri, 2004-01-23 at 03:45, Michel Dnzer wrote: On Fri, 2004-01-23 at 02:28, Michel Dnzer wrote: [...] (works with current libGL): Actually, most if not all textured apps spew [driAllocateTexture:577] unable to allocate texture all over the place and seem to fall back to software rendering. In contrast to the other problem, this doesn't occur on R100. Reverting Ian's commit from Wednesday doesn't help. But reverting Mesa/src/mesa/drivers/dri/common/texmem.c to revision 1.3 does. Keith, any idea what's up there? -- 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] radeon bugs
On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote: This is a good time to remind people/establish the principle that driver bug fixes should be propogated to the mesa-6_0_branch of the Mesa repository. Brian's always done a good job of making sure core mesa fixes get copied over, but it shouldn't come down to him alone. In particular, the recent TCL lighting fixes for the radeon r200 drivers should get pushed down into Mesa 6.0. Do we want to bring Mesa 6.0's branch into the DRI repository now or stick with the way we have it currently ? I guess if we stick with the way it is now, then most developers will track Mesa's trunk and we may start to lag stable releases. Alan. --- 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] radeon bugs
Alan Hourihane wrote: On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote: This is a good time to remind people/establish the principle that driver bug fixes should be propogated to the mesa-6_0_branch of the Mesa repository. Brian's always done a good job of making sure core mesa fixes get copied over, but it shouldn't come down to him alone. In particular, the recent TCL lighting fixes for the radeon r200 drivers should get pushed down into Mesa 6.0. Do we want to bring Mesa 6.0's branch into the DRI repository now or stick with the way we have it currently ? I guess if we stick with the way it is now, then most developers will track Mesa's trunk and we may start to lag stable releases. I like the way we have it now, to be truthful. If we develop on a branch or branches, we get little or no testing, and we really want testing. If someone wants a stable branch, they will be able to get one. It doesn't take too much effort to ensure bugfixes make their way onto the stable branch also. If someone has a bug with the stable branch, the information that it is fixed on the trunk will help track it down. What I'd really like to be able to do now is build the dri drivers directly out of the Mesa tree. 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] radeon bugs
On Tue, Jan 27, 2004 at 08:41:45PM +, Keith Whitwell wrote: Alan Hourihane wrote: On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote: This is a good time to remind people/establish the principle that driver bug fixes should be propogated to the mesa-6_0_branch of the Mesa repository. Brian's always done a good job of making sure core mesa fixes get copied over, but it shouldn't come down to him alone. In particular, the recent TCL lighting fixes for the radeon r200 drivers should get pushed down into Mesa 6.0. Do we want to bring Mesa 6.0's branch into the DRI repository now or stick with the way we have it currently ? I guess if we stick with the way it is now, then most developers will track Mesa's trunk and we may start to lag stable releases. I like the way we have it now, to be truthful. If we develop on a branch or branches, we get little or no testing, and we really want testing. I actually agree with you on this Keith. It's just too much of a pain to keep merging back and forward. If someone wants a stable branch, they will be able to get one. It doesn't take too much effort to ensure bugfixes make their way onto the stable branch also. If someone has a bug with the stable branch, the information that it is fixed on the trunk will help track it down. O.k. What I'd really like to be able to do now is build the dri drivers directly out of the Mesa tree. Definately. Slate that up for 6.1, I'll certainly work on that issue. Alan. --- 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] radeon bugs
Alan Hourihane wrote: What I'd really like to be able to do now is build the dri drivers directly out of the Mesa tree. Definately. Slate that up for 6.1, I'll certainly work on that issue. It's not too hard - I had it working on the embedded branch a while ago. In general, the Mesa make system could use a little modernization and spring cleaning. It'd be nice to see what improvements could be made with minimal or no additional toolchain requirements. Again - the embedded branch has/had a nice build system, although one that relied (very minimally) on GNU make. 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] radeon bugs
--- Alan Hourihane [EMAIL PROTECTED] wrote: On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote: This is a good time to remind people/establish the principle that driver bug fixes should be propogated to the mesa-6_0_branch of the Mesa repository. Brian's always done a good job of making sure core mesa fixes get copied over, but it shouldn't come down to him alone. In particular, the recent TCL lighting fixes for the radeon r200 drivers should get pushed down into Mesa 6.0. Do we want to bring Mesa 6.0's branch into the DRI repository now or stick with the way we have it currently ? I'm not sure I see the use. it's too late for xfree 4.4 and it'll be too old for 4.5 since by that time we'll be on to mesa 7 or 8. I guess if we stick with the way it is now, then most developers will track Mesa's trunk and we may start to lag stable releases. I think it's easier to have them in mesa, so that we can track the latest mesa fixes/features in the 3d drivers, but I'm not an expert. the only problem I can see is that we would have to merge mesa and dri into xfree86 when we did merges. either that or just package them separately. if a user wants 3D she/he will have to install a mesa package. then users can upgrade 3D without needing a new xfree86. Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ --- 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] radeon bugs
On Tue, Jan 27, 2004 at 01:17:20PM -0800, Alex Deucher wrote: --- Alan Hourihane [EMAIL PROTECTED] wrote: On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote: This is a good time to remind people/establish the principle that driver bug fixes should be propogated to the mesa-6_0_branch of the Mesa repository. Brian's always done a good job of making sure core mesa fixes get copied over, but it shouldn't come down to him alone. In particular, the recent TCL lighting fixes for the radeon r200 drivers should get pushed down into Mesa 6.0. Do we want to bring Mesa 6.0's branch into the DRI repository now or stick with the way we have it currently ? I'm not sure I see the use. it's too late for xfree 4.4 and it'll be too old for 4.5 since by that time we'll be on to mesa 7 or 8. I think you missed my point. It had no relation to XFree86 4.4.0. Alan. --- 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] radeon bugs
On Tue, 2004-01-27 at 21:41, Keith Whitwell wrote: Alan Hourihane wrote: Do we want to bring Mesa 6.0's branch into the DRI repository now or stick with the way we have it currently ? I guess if we stick with the way it is now, then most developers will track Mesa's trunk and we may start to lag stable releases. I like the way we have it now, to be truthful. If we develop on a branch or branches, we get little or no testing, and we really want testing. Agreed. What about a branch corresponding to the Mesa stable branch though? Then David could grab that for XFree86. What I'd really like to be able to do now is build the dri drivers directly out of the Mesa tree. Indeed, that'd be very nice. -- 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] Re: Re: Machine hangs/screen hangs with newer kernels + GL screensavers
On Wed, 2004-01-21 at 22:57, Marco van Zwetselaar wrote: Michel Daenzer wrote: Ariel Garcia wrote: both on my desktop and my laptop i am getting strange hangs when running XFree packages (both debian testing/unstable, 4.2.1-{12.1,15}) with the newer linux kernels. This happens for me since one of the 2.5.5* kernels (and it still happens BTW, it'd be interesting to know which 2.5.x kernel exactly it stopped working at. with 2.6.0) and now i also checked the same happens with 4.2.23 (but doesn't happen with 4.2.22). [...] I can confirm this. I got just the same problem on my laptop, a Dell with an ATI Radeon card, X version 4.2.1-12.1. When I start glxgears on kernel 2.4.23 or 2.6.0-test9, it all hangs. No problems on 2.4.22 (or earlier), which were configured just the same as .23, apart from the low latency patches (which aren't available yet for .23). Sounds like the radeon DRM broke backwards compatibility for XFree86 4.2 and older somewhere along the way. :( Just to be sure, can either of you please try the DRM from current DRI CVS? Should I file a bug in the BTS? Against what, the kernel packages? I'm not sure that'll be too useful, CC'ing the dri-devel list. -- 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] radeon bugs
On Wed, Jan 28, 2004 at 12:25:23AM +0100, Michel Dänzer wrote: On Tue, 2004-01-27 at 21:41, Keith Whitwell wrote: Alan Hourihane wrote: Do we want to bring Mesa 6.0's branch into the DRI repository now or stick with the way we have it currently ? I guess if we stick with the way it is now, then most developers will track Mesa's trunk and we may start to lag stable releases. I like the way we have it now, to be truthful. If we develop on a branch or branches, we get little or no testing, and we really want testing. Agreed. What about a branch corresponding to the Mesa stable branch though? Then David could grab that for XFree86. It's currently mesa_6_0_branch. Alan. --- 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] radeon bugs
On Wed, 2004-01-28 at 00:28, Alan Hourihane wrote: On Wed, Jan 28, 2004 at 12:25:23AM +0100, Michel Dnzer wrote: What about a branch corresponding to the Mesa stable branch though? Then David could grab that for XFree86. It's currently mesa_6_0_branch. Yes, I mean a corresponding branch in DRI CVS. -- 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] mesa test failures with radeon (7200)
Just for fun, tried all mesa demos/tests etc. with a radeon 7200 sdr. redbook/alpha3d: nothing is seen unless a is pressed (and then only for a very short time, buffering problem? (same as with r200) samples/fog: the red part seems to have the fog applied quite differently than with software mesa. samples/prim: the top right rectangle (I believe that's the quad strip) has a wrong color pattern (both with smooth and flat shade model, correct with poly line mode which uses fallback) - assuming that software mesa is correct of course, I have really no idea... Also, cycling through the colors, the original color pattern will never come back with software mesa - it will be completely blue instead. This works correctly with hardware acceleration. samples/tri: basically works, but seems to trigger a bug in software mesa (with LD_LIBRARY_PATH pointing to the standalone Mesa GL lib) for some reason sometimes. I couldn't figure out what keys need to be pressed exactly to trigger the bug, but it seems quite easy to reproduce. It will chew up all memory until the kernel kills it. At one time I was able to get some gdb output, looks the crash reason is some recursive loop: #0 0x40210172 in _tnl_copy_pv () from ../../lib/libGL.so.1 #1 0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1 #2 0x40210184 in _tnl_copy_pv () from ../../lib/libGL.so.1 #3 0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1 #4 0x40210184 in _tnl_copy_pv () from ../../lib/libGL.so.1 #5 0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1 #6 0x40210184 in _tnl_copy_pv () from ../../lib/libGL.so.1 #7 0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1 #8 0x40210184 in _tnl_copy_pv () from ../../lib/libGL.so.1 #9 0x40212382 in generic_copy_pv_extras () from ../../lib/libGL.so.1 (continued almost indefinitely, gdb was unable to get the outermost frames unfortunately) Doesn't seem to happen with hardware acceleration, but I'm not sure. xdemos/wincopy: second window empty (or random content) (same as with r200) seccolor: crashes with seccolor: radeon_state.c:741: radeonUpdateSpecular: Assertion `(p (1 21)) == 0' failed #3 0x401bf42f in __assert_fail () from /lib/i686/libc.so.6 #4 0x40598425 in radeonUpdateSpecular (ctx=0x8059a98) at radeon_state.c:741 #5 0x404a5608 in _mesa_set_enable (ctx=0x8059a98, cap=33880, state=1 '\001') at enable.c:991 #6 0x404a78cd in _mesa_Enable (cap=33880) at enable.c:1012 (this bug can also be triggered by demos/spectex) The assertion fails because the derived mesa state ctx-_TriangleCaps will only get calculated later. Removing the assertion makes seccolor work correctly. stencilwrap: fails every test (always returns 0 or 255, respectively). I also get: glxinfo: radeon_tex.c:696: radeonDeleteTexture: Assertion `t' failed. as well as application crashes when OGL applications (for instance QuakeIII) exit (this problem was present with r200 too but has already been fixed?). 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] undefined reference to '_mesa_init_driver_functions'
uilding shared library /opt/VTK/V4.0/VTK/bin/libvtkParallelJava.so... Building shared module /opt/VTK/V4.0/VTK/bin/libvtkParallelPython.so... Building shared library /opt/VTK/V4.0/VTK/bin/libvtkParallelTCL.so... ./Wrapping/Tcl: building default_target Building dependencies. cmake.depends... Building object file vtkTkAppInit.o... Building executable ../../../VTK/bin/vtk... /usr/X11R6/lib/libOSMesa.so: undefined reference to `_mesa_init_driver_functions' collect2: ld returned 1 exit status make[3]: *** [../../../VTK/bin/vtk] Fehler 1 make[2]: *** [default_target] Fehler 2 make[1]: *** [default_target_Wrapping_Tcl] Fehler 2 make: *** [default_target] Fehler 2 What's wrong? Cheers, 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
[Dri-devel] ATI IGP340M on 2.6 Success report
I've built DRI CVS along with Mesa CVS to get test my IGP340M on the 2.6.1 kernel. I'd like to report success. Note: this chipset has no TCL. glinfo (I cut GL_EXTENSIONS from here): disabling TCL support GL_VERSION: 1.2 Mesa 6.1 GL_RENDERER: Mesa DRI Radeon 20030328 AGP 4x x86/MMX/SSE2 NO-TCL GL_VENDOR: Tungsten Graphics, Inc. GLU_VERSION: 1.3 GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess GLUT_API_VERSION: 3 GLUT_XLIB_IMPLEMENTATION: 13 If anyone complains of getting the following errors at startx: mtrr: 0xf800,0x200 overlaps existing 0xf800,0x100 mtrr: 0xf800,0x200 overlaps existing 0xf800,0x100 [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held [drm:radeon_unlock] *ERROR* Process 13128 using kernel context 0 where process 13128 is X, tell them to make sure to load ati_igp if they enabled it as a module (2.6 now has the option to enable this as a module). Mesa demos results: @ 1024x768 @ 16bpp: glxgears reports: 2243 frames in 5.0 seconds = 448.600 FPS 2475 frames in 5.0 seconds = 495.000 FPS 2476 frames in 5.0 seconds = 495.200 FPS tunnel reports 52 FPS fire reports 31.8 FPS On `reflect` I see the reflection of the objects in stripes, not sure if this is how its supposed to look like. gloss: 537 frames in 5 seconds = 107.4 FPS 541 frames in 5.004 seconds = 108.114 FPS Quake 3 is next ;) Luis --- 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] ATI IGP340M on 2.6 Success report
If anyone complains of getting the following errors at startx: mtrr: 0xf800,0x200 overlaps existing 0xf800,0x100 mtrr: 0xf800,0x200 overlaps existing 0xf800,0x100 [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held [drm:radeon_unlock] *ERROR* Process 13128 using kernel context 0 where process 13128 is X, tell them to make sure to load ati_igp if they enabled it as a module (2.6 now has the option to enable this as a module). strikeati_igp/strike it's ati_agp ;) Luis --- 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] r200 texrect (current mesa/dri cvs) trouble
(since the original email never made it to the list, a new one - it's not a resend though) texrect is broken here (and I've no idea why it works for other people ;-)). There are 2 problems in the driver which cause this: First, if glGenTextures is called, there is no texture target yet. This will cause the r200 driver (in r200AllocTexObj) to initialize the texture min filter to GL_NEAREST_MIPMAP_LINEAR. The problem is when the texture object is now bound to a RECTANGLE_NV target, the min filter will not change, causing havoc (the also illegal clamp mode doesn't seem to hurt much). Second problem is the r200TexParameter, it will only do anything for 1D and 2D targets - thus, even if an application explicitly sets a different texture filter, the hardware will still try to use mipmapping for rectangle targets. Removing the target condition will fix this (why is it there? Mesa already should have checked illegal combinations, or are there some OGL compliant target/param combinations which are not supported in hardware?) Both problems are also present in the radeon driver, but texrect seems to work there nonetheless... attached a quick patch (only for r200, and I doubt it will attach cleanly, but I guess it's too ugly anyway). Roland Index: r200_tex.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_tex.c,v retrieving revision 1.12 diff -u -r1.12 r200_tex.c --- r200_tex.c 26 Jan 2004 23:57:19 - 1.12 +++ r200_tex.c 28 Jan 2004 01:47:05 - @@ -297,10 +297,10 @@ make_empty_list( t-base ); - r200SetTexWrap( t, texObj-WrapS, texObj-WrapT, texObj-WrapR ); +/* r200SetTexWrap( t, texObj-WrapS, texObj-WrapT, texObj-WrapR ); r200SetTexMaxAnisotropy( t, texObj-MaxAnisotropy ); r200SetTexFilter( t, texObj-MinFilter, texObj-MagFilter ); - r200SetTexBorderColor( t, texObj-_BorderChan ); + r200SetTexBorderColor( t, texObj-_BorderChan );*/ } return t; @@ -888,9 +1070,9 @@ _mesa_lookup_enum_by_nr( pname ) ); } - if ( ( target != GL_TEXTURE_2D ) +/* if ( ( target != GL_TEXTURE_2D ) ( target != GL_TEXTURE_1D ) ) - return; + return;*/ switch ( pname ) { case GL_TEXTURE_MIN_FILTER: @@ -950,6 +1132,13 @@ || (target == GL_TEXTURE_RECTANGLE_NV) ) { assert( texObj-DriverData != NULL ); } + r200TexObj * t = (r200TexObj *) texObj-DriverData; + + r200SetTexWrap( t, texObj-WrapS, texObj-WrapT, texObj-WrapR ); + r200SetTexMaxAnisotropy( t, texObj-MaxAnisotropy ); + r200SetTexFilter( t, texObj-MinFilter, texObj-MagFilter ); + r200SetTexBorderColor( t, texObj-_BorderChan ); + }
Re: [Dri-devel] r200 texrect (current mesa/dri cvs) trouble
Sorry for the spam, but I forgot another thing: in r200UploadRectSubImage, shouldn't r200AllocDmaRegion just call for a 1024 byte alignment (since the blit offset looks like it needs to be 1024 byte aligned)? That'll get rid of the failed assertion with texrect when using 16bit textures - the radeon driver already uses 1024 byte alignment. Also, the region.address used looks ugly - wouldn't it better to use region.address + region.start (I'm not sure how exactly that dma/region mechanism works, but I'd guess it might be possible that there is some other region used already in the same dma buffer which would get overwritten). 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] radeon bugs
On Tue, Jan 27, 2004 at 08:41:45PM +, Keith Whitwell wrote: What I'd really like to be able to do now is build the dri drivers directly out of the Mesa tree. Does this means that finally we will see XFree and linux-solo build it's drivers from Mesa-newtree/src/drivers/dri or this is not the case yet? -solca --- 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] i810 breakage in past few days..
the i810 got broken by the texture changes over the last few days, the imesa-i810Screen pointer wasn't setup before the call to mesa_create_context and it in turn called i810SetTexFilter which used IS_I815 which used i810Screen, I've checked in a fix (I've just moved all the pointer assignments before the function calls ..) 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] another texture compression patch (hopefully IP safe)
Dieter Nützel wrote: Am Freitag, 16. Januar 2004 20:00 schrieb Roland Scheidegger: ok, here's another attempt, which uses an external dxtn library (patch against current Mesa cvs trunk). And, again? - After texture merge. since you've asked ;-) fixes: - the dlopen stuff will no longer be built into libGLcore.a, so no more unresolved symbols and indirect rendering should work again (of course, without s3tc support). It will still break the build of mesa on platforms which don't support dlopen - some minor flaw fixed in the radeon and r200 texstate.c regarding to valid texture formats - should hopefully apply to mesa cvs again ;-) the compression library also got an update: - better handling of small color gradients (doesn't help much for Quake III high quality sky unfortunately) - very minor code cleanup, some small bugs fixed - it should be faster - thanks to the inclusion of the -O3 flag I forgot last time ;-) Sometimes it still produces completely wrong colors. I've only seen this with forced compression via driconf on textures with an alpha component, it might or might not be because even values which are completely transparent (and thus might have a completely arbitrary color value in the original) are used for the base color search. Roland libtxc_dxtn.tar.gz Description: Unix tar archive mesa_r200_radeon_txc.diff.gz Description: Unix tar archive
[Dri-devel] radeon bugs
There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes --- 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] radeon bugs
On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote: On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote: There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David, I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4, and the DRI developers aren't tracking Mesa 4.0.x anymore. We are at Mesa 5.0.2. Doesn't the DRI project maintain a Mesa 5.0.x-based stable branch of some sort? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes --- 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] radeon bugs
David Dawes wrote: On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote: On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote: There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David, I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4, and the DRI developers aren't tracking Mesa 4.0.x anymore. We are at Mesa 5.0.2. Doesn't the DRI project maintain a Mesa 5.0.x-based stable branch of some sort? David, The hardware drivers are now being maintained in the Mesa tree. Mesa does have a set of stable branches but the only one containing the DRI drivers is too recent for your purposes - Mesa 6.0. This is a good time to remind people/establish the principle that driver bug fixes should be propogated to the mesa-6_0_branch of the Mesa repository. Brian's always done a good job of making sure core mesa fixes get copied over, but it shouldn't come down to him alone. In particular, the recent TCL lighting fixes for the radeon r200 drivers should get pushed down into Mesa 6.0. 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] radeon bugs
On Tue, Jan 27, 2004 at 02:21:42PM -0500, David Dawes wrote: On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote: On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote: There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David, I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4, and the DRI developers aren't tracking Mesa 4.0.x anymore. We are at Mesa 5.0.2. Doesn't the DRI project maintain a Mesa 5.0.x-based stable branch of some sort? Whoops, sorry I meant to say 5.0.2. It's moved to Mesa 6.0 now, but I don't believe there's anyone maintaining a stable 5.0.2 branch. Alan. --- 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] radeon bugs
On Tue, Jan 27, 2004 at 07:52:32PM +, Alan Hourihane wrote: On Tue, Jan 27, 2004 at 02:21:42PM -0500, David Dawes wrote: On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote: On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote: There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David, I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4, and the DRI developers aren't tracking Mesa 4.0.x anymore. We are at Mesa 5.0.2. Doesn't the DRI project maintain a Mesa 5.0.x-based stable branch of some sort? Whoops, sorry I meant to say 5.0.2. It's moved to Mesa 6.0 now, but I don't believe there's anyone maintaining a stable 5.0.2 branch. OK, no worries. Are the still-open DRI-related bugs in bugs.xfree86.org fixed in Mesa 6.0? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes --- 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] Minimal fix for the R128 drivers
On Wed, Jan 14, 2004 at 01:39:39PM +, Alan Cox wrote: I think this is about the minimal fix needed. I'm not entirely happy with the limits picked, especially for spans, but maybe someone with an R128 can verify it is ok, or change the code to loop each chunk of pixels/span data. I've attached a version of the patch relative to the XFree86 version of this code, which I'm also committing there. Have there been any further updates on this? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes I've not yet looked at the new SiS allocator problems in detail. The 6326 really wants a different allocator anyway. Alan --- drivers/char/drm/r128_state.c~ 2004-01-14 13:42:38.0 + +++ drivers/char/drm/r128_state.c 2004-01-14 13:46:27.0 + @@ -23,8 +23,20 @@ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER * DEALINGS IN THE SOFTWARE. * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * RED HAT AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * THIS SOFTWARE IS NOT INTENDED FOR USE IN SAFETY CRITICAL SYSTEMS + * * Authors: *Gareth Hughes [EMAIL PROTECTED] + * + * Memory allocation size checks added 14/01/2003, Alan Cox [EMAIL PROTECTED] */ #include r128.h @@ -901,6 +913,9 @@ DRM_DEBUG( %s\n, __FUNCTION__ ); count = depth-n; + + if( count 4096 ) + return -EMSGSIZE; if ( copy_from_user( x, depth-x, sizeof(x) ) ) { return -EFAULT; } @@ -994,6 +1009,9 @@ DRM_DEBUG( %s\n, __FUNCTION__ ); count = depth-n; + + if( count 4096 ) + return -EMSGSIZE; x = kmalloc( count * sizeof(*x), GFP_KERNEL ); if ( x == NULL ) { @@ -1109,6 +1127,9 @@ DRM_DEBUG( %s\n, __FUNCTION__ ); count = depth-n; + + if ( count 4096 ) + return -EMSGSIZE; if ( copy_from_user( x, depth-x, sizeof(x) ) ) { return -EFAULT; } Index: r128_state.c === RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/r128_state.c,v retrieving revision 1.5 diff -u -r1.5 r128_state.c --- r128_state.c2 Dec 2003 13:02:43 - 1.5 +++ r128_state.c25 Jan 2004 02:55:20 - @@ -23,8 +23,20 @@ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER * DEALINGS IN THE SOFTWARE. * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * RED HAT AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * THIS SOFTWARE IS NOT INTENDED FOR USE IN SAFETY CRITICAL SYSTEMS + * * Authors: *Gareth Hughes [EMAIL PROTECTED] + * + * Memory allocation size checks added 14/01/2003, Alan Cox [EMAIL PROTECTED] */ #include r128.h @@ -915,6 +927,10 @@ DRM_DEBUG( \n ); count = depth-n; + + if ( count 4096 ) + return DRM_ERR(EMSGSIZE); + if ( DRM_COPY_FROM_USER( x, depth-x, sizeof(x) ) ) { return DRM_ERR(EFAULT); } @@ -1009,6 +1025,9 @@ count = depth-n; + if ( count 4096 ) + return DRM_ERR(EMSGSIZE); + xbuf_size = count * sizeof(*x); ybuf_size = count * sizeof(*y); x = DRM_MALLOC( xbuf_size ); @@ -1125,6 +1144,10 @@ DRM_DEBUG( \n ); count = depth-n; + + if ( count 4096 ) + return DRM_ERR(EMSGSIZE); + if ( DRM_COPY_FROM_USER( x, depth-x, sizeof(x) ) ) { return DRM_ERR(EFAULT); }