Re: [R300 and other radeons] MergedFB lockups
On Fri, 18 Feb 2005 20:06:53 -0500 (EST), Vladimir Dergachev [EMAIL PROTECTED] wrote: I think I found the cause of lockups in VB mode - they were due to cursor updating function in radeon_mergedfb.c calling OUTREGP() which in turn called INREG. When silken mouse is enabled this function could be called at any time which would do *bad* things when CP engine is active. The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. I have *no* idea why this worked with immediate mode at all and why no issues were reported by R200 and Radeon users (well, I only looked through the mailing lists, perhaps there is something on bugzilla but I don't know how to use that efficiently) I've never had any reports of this kind that I can think of for radeon or r200. Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. Does using the overlay also cause a lockup? there are some non-idled INREGs in there as well. I've never had a problem with them on r100 or r200 though. Alex --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
Vladimir Dergachev schrieb: I think I found the cause of lockups in VB mode - they were due to cursor updating function in radeon_mergedfb.c calling OUTREGP() which in turn called INREG. When silken mouse is enabled this function could be called at any time which would do *bad* things when CP engine is active. The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. I have *no* idea why this worked with immediate mode at all and why no issues were reported by R200 and Radeon users (well, I only looked through the mailing lists, perhaps there is something on bugzilla but I don't know how to use that efficiently) Well my rv250 lockups occour only during mouse movement in fullscreen applications. But for month ago there were no lockups. The situation was slowly getting worse since. With current DRM and Mesa driver I get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. Philipp --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon unified driver
Roland Scheidegger wrote: Since people have asked for it, I decided I'd give it a try... So here it is, a unified radeon driver (no not r300, only r100 and r200). http://homepage.hispeed.ch/rscheidegger/dri_experimental/ati_radeon.tar.bz2 exectuable generated will be called radeon_dri.so, for r200 you can just use a symlink. Basically this was just a mass copy/paste/search/replace job, there is very little new code in there. r100 changed more than r200, though: OLD_PACKETS, MAOS_VERTS are gone to make it look more like r200. Likewise, I've applied Andreas Stenglein's t_vertex patch (though for now there is actually not really any shared code for swtcl) from here, https://bugs.freedesktop.org/show_bug.cgi?id=2195. Also, radeon_compat and the subset stuff is gone (I'm not sure if this was actually up-to-date?). Required drm minor version was upped to 5 instead of 3, since that's the same as the r200 driver required. R100 theoretically also gained support for the client texturing stuff, since the code is not chip-specific it was moved to a common section. Both drivers should retain their current behaviour wrt to texture heaps/client texturing however. It is not fully unified, some code which could, and in some cases probably should be the same is still separate (most of sanity, swtcl, vtxfmt). In the end I actually ended up with almost everything in the generic radeon context, except vtxfmt and some variables which could easily be moved to it too... There is some problem with driconf, it seems to have some problems because the driver's name (radeon) does not match what it expects (r200). Likewise, I couldn't figure out how you'd have 2 separate config sections for both r100 and r200, currently you'll get all options of the r200 (though it won't work for that chip family...), some options just won't do anything on r100. Only tested on r200, and there are actually some visual anomalies in some games (ut2k3, startup logo and the special effects things like health pickups). No idea what's wrong, In ut2003 the bonuses seem to be the only thing that are drawn with more than 2 texture units. So it might be that texture units are broken beyond the second one. Stephane --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. Does using the overlay also cause a lockup? there are some non-idled INREGs in there as well. I've never had a problem with them on r100 or r200 though. Not anymore, I think I fixed all of those when importing GATOS code a while back. best Vladimir Dergachev Alex --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. I have *no* idea why this worked with immediate mode at all and why no issues were reported by R200 and Radeon users (well, I only looked through the mailing lists, perhaps there is something on bugzilla but I don't know how to use that efficiently) Well my rv250 lockups occour only during mouse movement in fullscreen applications. But for month ago there were no lockups. The situation was slowly getting worse since. With current DRM and Mesa driver I get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. Interesting :) Could you try this with latest X.org source ? Also, what is gl-117 ? thank you Vladimir Dergachev Philipp --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
Vladimir Dergachev schrieb: Interesting :) Could you try this with latest X.org source ? Sorry, but I probably won't find much time. I'll be away from the rv250 during the next week. Next month I'll have to write some exams, while at the beginning of april there are oral exams. I hope to find more time for DRI testing at the beginning of the next term. Also, what is gl-117 ? It's a free flight simulator, included in Debian. Philipp --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sat, 19 Feb 2005 09:56:33 -0500 (EST), Vladimir Dergachev [EMAIL PROTECTED] wrote: Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. Does using the overlay also cause a lockup? there are some non-idled INREGs in there as well. I've never had a problem with them on r100 or r200 though. Not anymore, I think I fixed all of those when importing GATOS code a while back. there's still one is the overlay gamma setup function, and I think another one further down. I can add the idle calls at some point this weekend unless someone beats me to it. Alex best Vladimir Dergachev Alex --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] VB lockup found and fixed
Nicolai Haehnle wrote: On Saturday 19 February 2005 01:05, Adam K Kirchhoff wrote: Nicolai Haehnle wrote: Please, everybody, get the latest CVS (anonymous will take some time to catch up...) and test vertex buffer mode with it (go to r300_run_render() in r300_render.c and change the #if so that r300_vb_run_render() is called). I want to be really sure that this fixes it for other people as well (after all, there may be other causes for lockups that haven't occured on my machine yet), and that there are no regressions for those who already had working VB mode. Correct me if I'm wrong, but to get the driver to automatically use vb mode, all you have to do is to change: #if 1 return r300_run_immediate_render(ctx, stage); #else return r300_run_vb_render(ctx, stage); #endif to #if 1 return r300_run_vb_render(ctx, stage); #else return r300_run_vb_render(ctx, stage); #endif Correct? That's correct, although it would be easier to just change the 1 into a 0 ;) Yeah, if I had actually taken the time to look at and understand the code, I would have just done that :-) If that's the case, I'm experiencing lockups with neverputt in both immediate and vb modes, though the symptoms are slightly different. In both cases, I have to ssh in and reboot. Simply killing neverputt doesn't bring back the machine. With immediate mode, the lockup seems to happen quicker. I can't get past the first hole. The mouse still responds.. I can move it around though, of course, it does no good. In vb mode, the mouse locks up, too. Any ideas? Interesting, I didn't have lockups that hard for quite some time. Then again, I'm only trying to get glxgears to run without lockups... So this could really be anything. The first rule of thumb is to run with the environment variable RADEON_DEBUG=all set and pipe stderr into a file (beware that this will reduce performance a lot), make sure you capture the entire file and examine that. The last line should be something like R200 timed out... exiting in normal lockups. So I updated my Xorg cvs, as per Vladimir's recent suggestion, and gave neverputt another shot. It locked up, including the mouse... It dies with: r300BindTexture( 0x831d050 ) unit=0 r300ResetHwState r300Flush r300FlushCmdBufLocked from r300Flush - 1 cliprects Syncing in r300FlushCmdBufLocked (from r300Flush) Error: R200 timed out... exiting I can upload the full debug log to a server at work, but it's about 62 megs and it's gonna take a while to upload. I'm attaching the last 200 lines or so. Adam TX_ENABLE: 0001 max_texture_unit=0 r300_check_render r300_run_render r300_run_vb_render r300ReleaseDmaRegion from r300ReleaseArrays r300ReleaseDmaRegion from r300ReleaseArrays r300ReleaseDmaRegion from r300ReleaseArrays Enabling VB-ObjPtr emit_vector count 78 size 3 stride 32 r300AllocDmaRegion 936 emit_vec12 count 78 stride 32 out 0xaec58968 data 0x8665dc0 Enabling VB-ColorPtr[0] emit_vector count 78 size 4 stride 16 r300AllocDmaRegion 1248 emit_vec16 count 78 stride 16 Enabling VB-TexCoordPtr[i] emit_vector count 78 size 2 stride 32 r300AllocDmaRegion 624 emit_vec8 count 78 stride 32 RR[0] - sz=3, reg=0, fmt=1 -- st=3, of=0x08149968 RR[1] - sz=4, reg=1, fmt=3 -- st=4, of=0x08149d10 RR[2] - sz=2, reg=2, fmt=1 -- st=2, of=0x0814a1f0 Reemit state after flush (from r300_run_vb_render) r300EmitState Begin reemit state Begin dirty state r300EmitState r300EmitAOS: nr=3, ofs=0x r300TexParameter( GL_TEXTURE_PRIORITY_EXT ) r300TexParameter( GL_TEXTURE_BORDER_COLOR ) r300TexParameter( GL_TEXTURE_BASE_LEVEL ) r300TexParameter( GL_TEXTURE_MAX_LEVEL ) r300BindTexture( 0x841f240 ) unit=0 r300TexParameter( GL_TEXTURE_PRIORITY_EXT ) r300TexParameter( GL_TEXTURE_BORDER_COLOR ) r300TexParameter( GL_TEXTURE_BASE_LEVEL ) r300TexParameter( GL_TEXTURE_MAX_LEVEL ) r300TexParameter( GL_TEXTURE_PRIORITY_EXT ) r300TexParameter( GL_TEXTURE_BORDER_COLOR ) r300TexParameter( GL_TEXTURE_BASE_LEVEL ) r300TexParameter( GL_TEXTURE_MAX_LEVEL ) r300TexParameter( GL_TEXTURE_PRIORITY_EXT ) r300TexParameter( GL_TEXTURE_BORDER_COLOR ) r300TexParameter( GL_TEXTURE_BASE_LEVEL ) r300TexParameter( GL_TEXTURE_MAX_LEVEL ) r300TexParameter( GL_TEXTURE_PRIORITY_EXT ) r300TexParameter( GL_TEXTURE_BORDER_COLOR ) r300TexParameter( GL_TEXTURE_BASE_LEVEL ) r300TexParameter( GL_TEXTURE_MAX_LEVEL ) r300TexParameter( GL_TEXTURE_PRIORITY_EXT ) r300TexParameter( GL_TEXTURE_BORDER_COLOR ) r300TexParameter( GL_TEXTURE_BASE_LEVEL ) r300TexParameter( GL_TEXTURE_MAX_LEVEL ) r300TexParameter( GL_TEXTURE_PRIORITY_EXT ) r300TexParameter( GL_TEXTURE_BORDER_COLOR ) r300TexParameter( GL_TEXTURE_BASE_LEVEL ) r300TexParameter( GL_TEXTURE_MAX_LEVEL ) r300TexParameter( GL_TEXTURE_PRIORITY_EXT ) r300TexParameter( GL_TEXTURE_BORDER_COLOR ) r300TexParameter( GL_TEXTURE_BASE_LEVEL ) r300TexParameter( GL_TEXTURE_MAX_LEVEL ) r300TexParameter(
Re: [R300 and other radeons] MergedFB lockups
On Sat, 19 Feb 2005, Alex Deucher wrote: On Sat, 19 Feb 2005 09:56:33 -0500 (EST), Vladimir Dergachev [EMAIL PROTECTED] wrote: Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. Does using the overlay also cause a lockup? there are some non-idled INREGs in there as well. I've never had a problem with them on r100 or r200 though. Not anymore, I think I fixed all of those when importing GATOS code a while back. there's still one is the overlay gamma setup function, and I think another one further down. I can add the idle calls at some point this weekend unless someone beats me to it. Ohh I see - these are triggerred only by changing Xv attributes and I don't think many people do this simultaneously with running 3d. I fixed it, no problem. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] VB lockup found and fixed
Adam K Kirchhoff wrote: Nicolai Haehnle wrote: On Saturday 19 February 2005 01:05, Adam K Kirchhoff wrote: Nicolai Haehnle wrote: Please, everybody, get the latest CVS (anonymous will take some time to catch up...) and test vertex buffer mode with it (go to r300_run_render() in r300_render.c and change the #if so that r300_vb_run_render() is called). I want to be really sure that this fixes it for other people as well (after all, there may be other causes for lockups that haven't occured on my machine yet), and that there are no regressions for those who already had working VB mode. Correct me if I'm wrong, but to get the driver to automatically use vb mode, all you have to do is to change: #if 1 return r300_run_immediate_render(ctx, stage); #else return r300_run_vb_render(ctx, stage); #endif to #if 1 return r300_run_vb_render(ctx, stage); #else return r300_run_vb_render(ctx, stage); #endif Correct? That's correct, although it would be easier to just change the 1 into a 0 ;) Yeah, if I had actually taken the time to look at and understand the code, I would have just done that :-) If that's the case, I'm experiencing lockups with neverputt in both immediate and vb modes, though the symptoms are slightly different. In both cases, I have to ssh in and reboot. Simply killing neverputt doesn't bring back the machine. With immediate mode, the lockup seems to happen quicker. I can't get past the first hole. The mouse still responds.. I can move it around though, of course, it does no good. In vb mode, the mouse locks up, too. Any ideas? Interesting, I didn't have lockups that hard for quite some time. Then again, I'm only trying to get glxgears to run without lockups... So this could really be anything. The first rule of thumb is to run with the environment variable RADEON_DEBUG=all set and pipe stderr into a file (beware that this will reduce performance a lot), make sure you capture the entire file and examine that. The last line should be something like R200 timed out... exiting in normal lockups. So I updated my Xorg cvs, as per Vladimir's recent suggestion, and gave neverputt another shot. It locked up, including the mouse... It dies with: r300BindTexture( 0x831d050 ) unit=0 r300ResetHwState r300Flush r300FlushCmdBufLocked from r300Flush - 1 cliprects Syncing in r300FlushCmdBufLocked (from r300Flush) Error: R200 timed out... exiting I can upload the full debug log to a server at work, but it's about 62 megs and it's gonna take a while to upload. I'm attaching the last 200 lines or so. Adam Same lockups with tuxracer, but it happened much quicker. You can view the full debug output from tuxracer at: http://go.visualtech.com/adam/tuxracer.txt It's about 6 megs in size. Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2578] New: [radeon] Rendering glitches in unreal tournament 2003
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2578 Summary: [radeon] Rendering glitches in unreal tournament 2003 Product: DRI Version: XOrg CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: libglx AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Using a Radeon 8500, Linux kernel 2.6.11-rc4 'radeon' driver, Xorg 6.8.2: :01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R200 QL [Radeon 8500 LE] When playing the game, things go fairly smoothly with the exception of some small problems. (1) In the menus, the mouse pointer is shadowed. I'll draw this in some lovely ascii art. |\ || | \ || | \|| | \ || \-+-/ || \|| \ || ^ ^ cursorshadow The shadow follows the mouse cursor around when you move it. (2) Shadows in some part of levels are purple. The purple also shows up in some objects (like in +50 shield pack) where it isn't supposed to. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Mesa texture format REV
Hi, I wanted to know how i can ask mesa to give me the texture in a specified order. i.e. actually mesa give me texture in RGBA_REV while i want it in RGBA I have tried to have by specifing GL_UNSIGNED_INT_8_8_8_8_REV to the format parameter of glTexImage2D This effectively leads mesa to see texture in rev order (i am in big endian so it sees RGBA not RGBA_REV) but mesa do the conversion and send me the texture always in same order (RGBA_REV). Thus what ever i put for format : GL_UNSIGNED_INT_8_8_8_8_REV or GL_UNSIGNED_INT_8_8_8_8 I get the texture in the same format in the driver (r300) i really would like to test all texture format, so is there a way to ask mesa to send me texture in a specific order (REV or not) Thx Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Mesa texture format REV
Jerome Glisse wrote: Hi, I wanted to know how i can ask mesa to give me the texture in a specified order. i.e. actually mesa give me texture in RGBA_REV while i want it in RGBA I have tried to have by specifing GL_UNSIGNED_INT_8_8_8_8_REV to the format parameter of glTexImage2D This effectively leads mesa to see texture in rev order (i am in big endian so it sees RGBA not RGBA_REV) but mesa do the conversion and send me the texture always in same order (RGBA_REV). Thus what ever i put for format : GL_UNSIGNED_INT_8_8_8_8_REV or GL_UNSIGNED_INT_8_8_8_8 I get the texture in the same format in the driver (r300) i really would like to test all texture format, so is there a way to ask mesa to send me texture in a specific order (REV or not) No. The format parameter describes the incoming format of the user's texture image. It may or may not have any bearing on which hardware format is chosen by the driver. More typically, the internalFormat parameter is used by the driver to choose the hardware texture format. Not all the MESA_FORMAT_* texture formats are supported by all drivers. -Brian --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Mesa texture format REV
in the driver (r300) i really would like to test all texture format, so is there a way to ask mesa to send me texture in a specific order (REV or not) No. The format parameter describes the incoming format of the user's texture image. It may or may not have any bearing on which hardware format is chosen by the driver. More typically, the internalFormat parameter is used by the driver to choose the hardware texture format. Not all the MESA_FORMAT_* texture formats are supported by all drivers. I see. Brian, would you know - do we *have* to use _dri_texformat_xxx formats for hardware formats ? The reason I am asking is that R300 appears to support all (or almost all) GL texture formats and it would not be too difficult to add this support, but we are using R200 switch() due to lack of understanding of Mesa-driver interface. thank you ! Vladimir Dergachev -Brian --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Mesa texture format REV
No. The format parameter describes the incoming format of the user's texture image. It may or may not have any bearing on which hardware format is chosen by the driver. More typically, the internalFormat parameter is used by the driver to choose the hardware texture format. I am standing from the driver point of view, and so i wanted to know if i can ask mesa, from the driver, for a special order. In r300 driver we have to test find the hardware texture format and for testing all possible path i would like to have the texture provided by mesa in rev or not rev order as internal mesa can give it to me in this two format. What i found is that on big endian machine i get the texture in REV order while on little endian i get it in normal order. Anyway if it isn't possible to ask mesa for having texture in rev or not order, i can assume that on big endian machine i will always have texture in rev while on x86 i will get it in normal order ? Not all the MESA_FORMAT_* texture formats are supported by all drivers. I think that r300 could support all mesa's texture format :) thx for your help Jerome Glisse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] VB lockup found and fixed
Vladimir Dergachev wrote: Adam Same lockups with tuxracer, but it happened much quicker. You can view the full debug output from tuxracer at: http://go.visualtech.com/adam/tuxracer.txt It's about 6 megs in size. I suggest you gzip it next time - this should work exceedingly well with log files and most people can still view it within a webbrowser. Also, to cover the obvious, you did update the DRM driver, recompile it and reloaded it ? Check that there are no stray binaries around.. Sorry 'bout that. Yeah, the DRM was updated as well. I've compared md5sums on the drm.ko and radeon.ko modules in /lib/modules/2.6.10/kernel/drivers/char/drm to the ones in the drm directory of r300_driver tree that I just built from this morning. Exact match. Even after doing a make clean in the drm source directory and rebuilding it just now, they match. I'm not sure what stray binaries would cause this.. However, libGL.so is definitely loading /usr/X11R6/lib/modules/dri/r300_dri.so, and I build and installed that this morning (and have since updated it this afternoon). Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2579] New: Poor FPS ( 200) on Radeon IGP 320M (HP Compaq Presario 900US)
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2579 Summary: Poor FPS ( 200) on Radeon IGP 320M (HP Compaq Presario 900US) Product: DRI Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: General AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Gentoo 2004.3, 2.6.10 kernel, XOrg-6.8.2 (using the in-kernel DRM from Linux 2.6.10, and the radeon driver from XOrg-6.8.2) Also reproduced w/ Radeon DRI snapshot 20050219 (http://dri.freedesktop.org/snapshots/radeon-20050219-linux.i386.tar.bz2) (using DRM kernel module from snapshot, not from Linux kernel) Acceleration is enabled, but glxgears still runs pretty slow w/ this setup, yielding: 953 frames in 5.0 seconds = 190.600 FPS 990 frames in 5.0 seconds = 198.000 FPS 990 frames in 5.0 seconds = 198.000 FPS 993 frames in 5.0 seconds = 198.600 FPS 988 frames in 5.0 seconds = 197.600 FPS This seems pretty slow for accelerated rendering. At least, it seems that all of the load is on the graphics card, and none of it on the CPU. I've already fixed the DSDT in this laptop (and I've posted my fix to acpi.sf.net) but it didn't create any speed improvements. Any help would be greatly appreciated! I've got a desktop machine with an older, cheaper (assumedly less powerful?) Radeon card (Radeon 7000 VE [RV100 QY]), but I've at least gotten that thing to push just shy of 500 FPS. In case it helps, my machine is an Athlon XP 1800+, with 512MB of RAM. lspci says: :00:00.0 Host bridge: ATI Technologies Inc AGP Bridge [IGP 320M] (rev 13) :00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 320M] (rev 01) :00:02.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) :00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV] :00:08.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02) :00:0a.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02) :00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 20) :00:0c.0 Communication controller: Conexant HSF 56k HSFi Modem (rev 01) :00:0f.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) :00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4) :00:11.0 Bridge: ALi Corporation M7101 Power Management Controller [PMU] :00:13.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) :01:05.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility U1 :02:00.0 Network controller: Intersil Corporation Intersil ISL3890 [Prism GT/Prism Duette] (rev 01) --- I've tried various optimization-related options in xorg.conf, but to no avail, so I just have them commented out now. my current xorg.conf is: --- Section ServerLayout Identifier X.org Configured Screen 0 Screen0 0 0 InputDeviceMouse0 CorePointer InputDeviceMouse1 AlwaysCore InputDeviceKeyboard0 CoreKeyboard EndSection Section Files RgbPath /usr/lib/X11/rgb ModulePath /usr/lib/modules FontPath /usr/share/fonts/misc/ FontPath /usr/share/fonts/TTF/ FontPath /usr/share/fonts/Type1/ FontPath /usr/share/fonts/CID/ FontPath /usr/share/fonts/75dpi/ FontPath /usr/share/fonts/100dpi/ EndSection Section Module Load extmod Load dri Load dbe Load record Load xtrap Load glx Load type1 Load freetype Load synaptics EndSection Section ServerFlags Option RandR on EndSection Section InputDevice Identifier Keyboard0 Driver kbd EndSection Section InputDevice Identifier Mouse0 Driver synaptics Option Protocol auto-dev Option Device /dev/psaux Option LeftEdge 1700 Option RightEdge 5300 Option TopEdge 1700 Option BottomEdge4200 Option FingerLow 25 Option FingerHigh30 Option MaxTapTime180 Option MaxTapMove220 Option VertScrollDelta 100 Option MinSpeed 0.09 Option MaxSpeed 0.18 Option AccelFactor 0.0015 Option SHMConfig on # Option Repeater /dev/ps2mouse EndSection Section InputDevice
Re: [Mesa3d-dev] Mesa texture format REV
Jerome Glisse wrote: No. The format parameter describes the incoming format of the user's texture image. It may or may not have any bearing on which hardware format is chosen by the driver. More typically, the internalFormat parameter is used by the driver to choose the hardware texture format. I am standing from the driver point of view, and so i wanted to know if i can ask mesa, from the driver, for a special order. In r300 driver we have to test find the hardware texture format and for testing all possible path i would like to have the texture provided by mesa in rev or not rev order as internal mesa can give it to me in this two format. What i found is that on big endian machine i get the texture in REV order while on little endian i get it in normal order. Anyway if it isn't possible to ask mesa for having texture in rev or not order, i can assume that on big endian machine i will always have texture in rev while on x86 i will get it in normal order ? I'm not 100% sure I understand your question, but here's now things work. When glTexImageXD() is called, the ctx-Driver.ChooseTextureFormat() function is called. This gives the driver the opportunity to examine the user's internalFormat, format and type parameters and choose the appropriate texture format, such as _mesa_texformat_rgb565. In the r200 driver, this is done in the r200ChooseTextureFormat() function. That function will only choose texture formats that are actually supported by the hardware. I think the function is pretty self-explanatory. For the r300 driver you'd write a similar function, but the selection criteria can be anything you want. For example, you could test the format parameter for GL_UNSIGNED_INT_8_8_8_8 vs GL_UNSIGNED_INT_8_8_8_8_REV and either choose _mesa_texformat_rgba or _mesa_texformat_rgba_rev. Once you've chosen the texture format. Mesa will convert the incoming user texture image to the chosen destination format. Mesa can handle all possible (legal) conversions. Not all the MESA_FORMAT_* texture formats are supported by all drivers. I think that r300 could support all mesa's texture format :) OK. -Brian --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon unified driver
Am Samstag, den 19.02.2005, 01:11 +0100 schrieb Nicolai Haehnle: Hi, On Saturday 19 February 2005 00:46, Roland Scheidegger wrote: There is some problem with driconf, it seems to have some problems because the driver's name (radeon) does not match what it expects (r200). Likewise, I couldn't figure out how you'd have 2 separate config sections for both r100 and r200, currently you'll get all options of the r200 (though it won't work for that chip family...), some options just won't do anything on r100. When I started working on the R300 driver, I did some similar work so that the R300 driver should in theory be able to handle R200 as well (this R200 support has certainly gone to hell by now because of all the hacking that has been going on). The point is, I also faced the driconf issue, and you can see how I attempted to tackle it at http://cvs.sourceforge.net/viewcvs.py/r300/r300_driver/r300/radeon_screen.c?rev=1.7view=auto My solution is probably not that good, but it might give you some ideas. This is not going to work with the GUI configuration tool. It looks for a symbol called __driConfigOptions in the driver module, so with your change driconf would claim that the driver doesn't support configuration. It can't call the driver to probe on which hardware it's running, so you can't use different sets of options for different hardware supported by the same driver. I have the same problem in the savage driver. Some options just don't make sense on Savage3D-based hardware, so they have no effect in this case (for example floating-point depth buffer). So, when I read the configuration I have code like this in the driver: imesa-float_depth = driQueryOptionb(imesa-optionCache, float_depth) savageScreen-chipset = S3_SAVAGE4; Additionally you could put hardware-specific options into separate sections, so that the user can tell, which options will have an effect on her hardware. cu, Nicolai Regards, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Mesa texture format REV
Vladimir Dergachev wrote: in the driver (r300) i really would like to test all texture format, so is there a way to ask mesa to send me texture in a specific order (REV or not) No. The format parameter describes the incoming format of the user's texture image. It may or may not have any bearing on which hardware format is chosen by the driver. More typically, the internalFormat parameter is used by the driver to choose the hardware texture format. Not all the MESA_FORMAT_* texture formats are supported by all drivers. I see. Brian, would you know - do we *have* to use _dri_texformat_xxx formats for hardware formats ? It looks like the _dri_texformat_* variables are just pointers to the _mesa_texformat_* instances. You can use any of those, or invent new formats. You just have to declare a struct gl_texture_format foobar variable and initialize all its fields. See texformat.[ch] and texformat_tmp.h for examples. The reason I am asking is that R300 appears to support all (or almost all) GL texture formats and it would not be too difficult to add this support, but we are using R200 switch() due to lack of understanding of Mesa-driver interface. Well, even if the hardware does support all the present Mesa texture formats doesn't mean you _have_ to use them all. The end user isn't really going to care. -Brian --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sat, 2005-02-19 at 11:23 +0100, Philipp Klaus Krause wrote: Vladimir Dergachev schrieb: I think I found the cause of lockups in VB mode - they were due to cursor updating function in radeon_mergedfb.c calling OUTREGP() which in turn called INREG. When silken mouse is enabled this function could be called at any time which would do *bad* things when CP engine is active. The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. I have *no* idea why this worked with immediate mode at all and why no issues were reported by R200 and Radeon users (well, I only looked through the mailing lists, perhaps there is something on bugzilla but I don't know how to use that efficiently) Well my rv250 lockups occour only during mouse movement in fullscreen applications. But for month ago there were no lockups. The situation was slowly getting worse since. With current DRM and Mesa driver I get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel (well, actually, all of the above are about 5 days old, doesn't have Vladimir latest fixes), I get very jerky display with g117 and broken textures, ultimately it locks up after moving the mouse a little bit (at the meny screen). I can kill X tho, that works, so the chip/bus isn't totally dead (or it recovers with an engine reset). Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Saturday 19 February 2005 02:06, Vladimir Dergachev wrote: I think I found the cause of lockups in VB mode - they were due to cursor updating function in radeon_mergedfb.c calling OUTREGP() which in turn called INREG. When silken mouse is enabled this function could be called at any time which would do *bad* things when CP engine is active. The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. I have *no* idea why this worked with immediate mode at all and why no issues were reported by R200 and Radeon users (well, I only looked through the mailing lists, perhaps there is something on bugzilla but I don't know how to use that efficiently) Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. I can see no difference at all with this latest change, i.e. no regressions, but the lockup is still there. cu, Nicolai best Vladimir Dergachev pgpwdAI9btdc8.pgp Description: PGP signature
Re: Xgl + mga
No on has tried getting XGL running on top of mesa-solo. I don't know of any obvious reason why it shouldn't work other than no one has tried doing it yet. First check out that your mga mesa-solo is running, there are test programs in the mesa tree for this. Then try to get XGL running on top. This may require some work to XGL but post your issues to the [EMAIL PROTECTED] and [EMAIL PROTECTED] lists and someone will answer. building an Xserver on top of mesa solo is a bit of a nightmare in terms of includes and defines .. as an Xserver requires all the X types to build but solo has its own set of defines/typedefs that don't match what the Xserver has... so calling XCreateWindow is a bit painful for example... glitz-glx also includes X headers... (not sure if it really needs them as glx.h should pull in any necessary headers... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Mesa texture format REV
The reason I am asking is that R300 appears to support all (or almost all) GL texture formats and it would not be too difficult to add this support, but we are using R200 switch() due to lack of understanding of Mesa-driver interface. Well, even if the hardware does support all the present Mesa texture formats doesn't mean you _have_ to use them all. The end user isn't really going to care. Is there no penalty for format conversion ? Vladimir Dergachev -Brian --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. I can see no difference at all with this latest change, i.e. no regressions, but the lockup is still there. I think we can safely assume that there is more than one issue. For example, I am often seeing about 2-sec delay upon the start of a GL app (all 2d updates are frozen). The delay always happens upon the first GL context after a cold reboot, and it is often not present on successive launches of GL apps. I just tried to check for partly covered window lockup bug - glxgears appears to be entirely indifferent to whether anything is covering it. As for gl-117 - I just tried it and it segfaults due to undefined functions to handle vertex buffers. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel (well, actually, all of the above are about 5 days old, doesn't have Vladimir latest fixes), I get very jerky display with g117 and broken textures, ultimately it locks up after moving the mouse a little bit (at the meny screen). Is it a hard lockup ? With R300 it segfaults when I move a mouse due to vertex arrays code not written yet, however it is strange this happens only after a mouse movement. It could be that it tramples over some Mesa driver memory (or there is a bug in Mesa driver/library). best Vladimir Dergachev I can kill X tho, that works, so the chip/bus isn't totally dead (or it recovers with an engine reset). Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sat, 2005-02-19 at 23:22 -0500, Vladimir Dergachev wrote: [...] For example, I am often seeing about 2-sec delay upon the start of a GL app (all 2d updates are frozen). The delay always happens upon the first GL context after a cold reboot, and it is often not present on successive launches of GL apps. I see this on my R200 on amd64, as well. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sat, 19 Feb 2005, Vladimir Dergachev wrote: get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel (well, actually, all of the above are about 5 days old, doesn't have Vladimir latest fixes), I get very jerky display with g117 and broken textures, ultimately it locks up after moving the mouse a little bit (at the meny screen). Is it a hard lockup ? With R300 it segfaults when I move a mouse due to vertex arrays code not written yet, however it is strange this happens only after a mouse movement. One more thing: go to ~/.gl-117 and edit the file conf to turn off full screen mode. Reduce the resolution to something small (like 640x480). Now you would be able to run it under debugger and see where it segfaults. I am curious to see where the problem is in rv250 driver. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sat, 19 Feb 2005, Eric Anholt wrote: On Sat, 2005-02-19 at 23:22 -0500, Vladimir Dergachev wrote: [...] For example, I am often seeing about 2-sec delay upon the start of a GL app (all 2d updates are frozen). The delay always happens upon the first GL context after a cold reboot, and it is often not present on successive launches of GL apps. I see this on my R200 on amd64, as well. Really ? Do you have DynamicClocks on ? Do you have ACPI in the kernel ? I have no idea what could have caused such a delay, as microcode has long been loaded by then. best Vladimir Dergachev -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sat, 2005-02-19 at 23:25 -0500, Vladimir Dergachev wrote: get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel (well, actually, all of the above are about 5 days old, doesn't have Vladimir latest fixes), I get very jerky display with g117 and broken textures, ultimately it locks up after moving the mouse a little bit (at the meny screen). Is it a hard lockup ? With R300 it segfaults when I move a mouse due to vertex arrays code not written yet, however it is strange this happens only after a mouse movement. It could be that it tramples over some Mesa driver memory (or there is a bug in Mesa driver/library). Well, difficult to say, I didn't manage to get back to X, but I managed to kill X and radeonfb managed to restore the display, at which point I could re-launch X... best Vladimir Dergachev I can kill X tho, that works, so the chip/bus isn't totally dead (or it recovers with an engine reset). Ben. -- Benjamin Herrenschmidt [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
