[Bug 768] r128 t_vertex.c conversion
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://freedesktop.org/bugzilla/show_bug.cgi?id=768 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|dri-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | --- Additional Comments From [EMAIL PROTECTED] 2004-06-21 01:08 --- Okay, so ajax was bugging me to put my diff up like I said I would, and I thought I hadn't messed things up since the point that they were basically working, so I just test-compiled again and threw it up here. Here's a new version, with t_dd_triemit.h fixed up for r128 and being actually used, the fix for bug 755, and some attempts at fixing something new I noticed: tuxracer's colors are wacky. Other issue I noticed: Lack of SpanRenderStart/SpanRenderFinish around the fallback primitives. t_dd_triemit.h notes: Do other cards need the CPU_TO_LE32? If not, why is r128 special? Should it be a required define (to 0 or 1, like other HAVE_*)? Need to work on other code for a while, though. Review welcome, but this is quite unfinished I guess. -- Configure bugmail: http://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Introduce DRI_VERSION?
On Sun, Jun 20, 2004 at 11:27:56AM -0700, Eric Anholt wrote: On Sun, 2004-06-20 at 11:17, Ian Molton wrote: On Thu, 17 Jun 2004 11:00:33 -0700 Alan Coopersmith [EMAIL PROTECTED] wrote: The big dri merge seems a good time to label snapshot 6.7.0.90 or however we want to start identifying the pre-6.7.1 snapshots. (How do we want to do that?) that .90 numbering is hideous. whats wrong with -preX ? Yeah, here's a vote for that, as well. And for tarring a snapshot at this point, if we could. It doesn't fit into x.y.z.a, that's why. Internally, KDE at least maps its versions to numbers (e.g. 3.0a1 - 2.99.1/029901). Also sucks for us packagers (2.9+3.0alpha1 as version numbers are horrific, and this braindamage is all through Debian). I see the argument for it, but the argument against is compelling; in this case we need numeracy anyway, so we might as well shoot for consistency. -- Daniel Stone[EMAIL PROTECTED] freedesktop.org: powering your desktophttp://www.freedesktop.org signature.asc Description: Digital signature
[Bug 770] Hangs with chromium using CVS as of 20040531
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://freedesktop.org/bugzilla/show_bug.cgi?id=770 --- Additional Comments From [EMAIL PROTECTED] 2004-06-21 06:13 --- multiple GL apps are currently busted on R200. check the dri-devel archives for Roland's thread about this. render probably triggers this as well since it uses the 3d engine. -- Configure bugmail: http://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 762] GL_HP_occlusion_test broken due to mismatch in depth bits
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://freedesktop.org/bugzilla/show_bug.cgi?id=762 --- Additional Comments From [EMAIL PROTECTED] 2004-06-21 09:54 --- Created an attachment (id=401) -- (http://freedesktop.org/bugzilla/attachment.cgi?id=401action=view) Log depth values when occlusion testing is active This is the patch I used to log the depth values when occlusion testing is active. This causes quite a lot of data to be sent to the log, so be careful using it. :) You'll also need to enable GL_HP_occlusion_test on both client-side and server-side. That's as easy has changing a '#if 0' in xc/xc/lib/GL/glx/glxextensions.c and one in xc/xc/programs/Xserver/GL/glx/glxscreens.c. -- Configure bugmail: http://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 5:00PM EDT or 2:00PM PDT, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 787] New: Mach64: works fine, after reboot using opengl freezes X
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://freedesktop.org/bugzilla/show_bug.cgi?id=787 Summary: Mach64: works fine, after reboot using opengl freezes X Product: DRI Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: blocker Priority: P2 Component: General AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am using the 20040621 snapshots with a 2.4.26 kernel and Xfree86 4.3.0 with the replacing binary from http://dri.sourceforge.net/cgi-bin/moin.cgi/XFree86. After compiling and installing DRI using install.sh i restarted X and everything worked fine, glxgears gave me 260-300 FPS instead of the software-rendered 60 FPS. But then, after restarting, starting any opengl using application causes the system to freeze, although it is still accessible by ssh. After killing the application X is screwed, see http://sven.gotdns.org/~sven/hm.png, this can only be fixed by rebooting. The weird thing is that everything tells me DRI was initialized properly. some output: [EMAIL PROTECTED]:~$ export LIBGL_DEBUG=verbose [EMAIL PROTECTED]:~$ glxinfo name of display: :0.0 libGL: XF86DRIGetClientDriverName: 6.5.3 mach64 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/mach64_dri.so drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:00.0 libGL error: Can't open configuration file /home/sven/.drirc: No such file or directory. display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_SGI_video_sync, GLX_SGIS_multisample OpenGL vendor string: Gareth Hughes, Leif Delgass, José Fonseca OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20030502 x86/MMX OpenGL version string: 1.2 Mesa 6.1 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_object, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_IBM_rasterpos_clip, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_light_max_exponent, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod 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 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x25 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x28 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x29 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2a 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x2b 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x2c 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x2d 16 dc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2e 16 dc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0
Re: Thread Local Storage libGL
Ian Romanick wrote: Ian Romanick wrote: Ian Romanick wrote: Alan Hourihane wrote: Is there someone looking to integrate the TLS patches for libGL ?? We should certainly take a look soon and comment upon the patches used. Here is a patch that covers part of what's in the Redhat patch. This convert the static_functions table to a list of offsets instead of a list of pointers. According to 'objdump -R' on the Mesa libGL, it cuts out about 1800 R_386_RELATIVE relocs. However, the size of the library *increases* by about 24k. That doesn't make sense to me. Here's an updated version of that patch. There are some significant differences. 1. *All* architectures use the string offset table. To do this, gl_procs.py was modified to generate a big character array called gl_string_table in glprocs.h. The static_functions array now contains offsets into that array instead of pointers to strings. If gl_procs.py is invoked with '-m short' it will generate a (hard to read) character array. If it is invoked with no option or '-m long' it will generate a big (~16k) string. The string version of the .h file generates a warning from GCC. 2. The same glprocs.h is used even for the optimized x86 case. This is done by defining NEED_FUNC_POINTERS only on non-x86. Actually, it should only be defined on architectures that don't have generated assembly dispatch stubs. 3. All of the _ts_ dispatch code is *gone*. The x86 assembly dispatch code and the C dispatch code reflect this. The SPARC assembly dispatch has not yet been updated, but it should follow the x86 model. This means that this cod will catch fire, fallover, and sink into the swamp on SPARC. This will obviously need to be fixed before that portion of the patch is committed. Unless there are objections, I would like to commit the new glprocs.h and the non-x86 specific code in glapi.c to support it. This patch is about the final form, I hope. It builds on the previous version by replacing all _glapi_Dispatch-Foo calls with the GL_CALL macro. In addition to several programs from progs/demos, this patch has been tested with progs/xdemos/glthreads with 20 threads. The previous patch would die in glthreads because, in the threaded case, _glapi_Dispatch is NULL. That shouldn't have been a big surprise to me since that's most of the point of that patch! Duh! Conceptually, this is similar to the GL_CALL macro in Jakub's patch, but it does not directly call the dispatch function in the threaded case. Since we can't call the dispatch functions from with in a *_dri.so, it inlines the dispatch function. As a nice side effect, dispatch.c uses GL_CALL to define DISPATCH and RETURN_DISPATCH. The GL_CALL macro currently lives in glthread.h because it might use some threading related functions. The pthreads-specific version directly calls pthread_getspecific, for example. For functions that have a lot of GL_CALL invocations, it might be possible to make a new macro, GL_CALL_GET_DISPATCH or something, to cache the dispatch table pointer. This should make the compiled code a lot smaller and reduce the performance hit in the threaded case. Note that the performance hit in the threaded case was just as bad (maybe worse) when the _ts_ dispatch functions were used. Like I threatened yesterday (heh), tomorrow (Wednesday) I plan to commit the following parts of this patch: 1. The new glprocs.h (generated with 'python2 gl_procs.py -m short') and the non-x86 specific code to support it. 2. The GL_CALL changes and the non-threaded version of the macro. That's the one that looks like #define GL_CALL(name) (_glapi_Dispatch- name). My hope is that we can discuss the remaining changes in the patch at Monday's #dri-devel chat. I should be able to get some performance numbers out later today. This patch is the same as the -03 patch except it is against today's CVS. Also, you *MUST* regenerate glapi_x86.S on your own. Including that file made the patch way to big to get through the list. :) You can do this by doing (after applying the patch): cd src/mesa/glapi python2 gl_x86_asm.py ../x86/glapi_x86.S Index: src/mesa/glapi/gl_x86_asm.py === RCS file: /cvs/mesa/Mesa/src/mesa/glapi/gl_x86_asm.py,v retrieving revision 1.1 diff -u -d -r1.1 gl_x86_asm.py --- src/mesa/glapi/gl_x86_asm.py18 May 2004 18:33:40 - 1.1 +++ src/mesa/glapi/gl_x86_asm.py21 Jun 2004 21:17:25 - @@ -77,15 +77,65 @@ print '#define GLOBL_FN(x) GLOBL x' print '#endif' print '' - print '#define GL_STUB(fn,off,stack)\t\t\t\t\\' + print '#if defined(PTHREADS)' + print '# define GL_STUB(fn,off,fn_alt)\t\t\t\\' print 'ALIGNTEXT16;\t\t\t\t\t\t\\' - print 'GLOBL_FN(GL_PREFIX(fn, fn ## @ ## stack));\t\t\\' - print 'GL_PREFIX(fn, fn ## @ ##
[Bug 788] New: Display Artifacts at 1680x1050
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://freedesktop.org/bugzilla/show_bug.cgi?id=788 Summary: Display Artifacts at 1680x1050 Product: DRI Version: DRI CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: General AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] (pasted together from some IRC snippets) There's a bug in the r200 driver when using 1600 pixels wide resolutions. See http://steffen-hein.de/misc/images/r200-dri-bug-1680.jpg On the left and right side - these areas only get partly updated q3 screen-mode: PIXELFORMAT: color(32-bits) Z(24-bit) stencil(8-bits) MODE: -1, 1680 x 1050 fullscreen hz:N/A GAMMA: hardware w/ 0 overbright bits MrCooper sth_: what does 'grep pitch /var/log/XFree86.0.log' say? sth_ (--) RADEON(0): Virtual size is 1680x1050 (pitch 1680) MrCooper sth_: the depth buffer pitch may be invalid MrCooper sth_: it must be a multiple of 32 pixels, but it looks like the radeon 2D driver just takes the colour buffer pitch -- Configure bugmail: http://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 788] Display Artifacts at 1680x1050
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://freedesktop.org/bugzilla/show_bug.cgi?id=788 --- Additional Comments From [EMAIL PROTECTED] 2004-06-21 15:41 --- MrCooper sth_: so, can you try rounding up the depth pitch to a multiple of 32 pixels? (or maybe using a multiple of 32 horizontal width for a start) MrCooper sth_: I mean virtual width of course sth_ MrCooper: Setting the XServer virtual resolution to something like 1696? MrCooper sth_: exactly I added Virtual 1696 1050 to my XF86Config-4, restarted X11 and the problem disappeared. -- Configure bugmail: http://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 787] Mach64: works fine, after reboot using opengl freezes X
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://freedesktop.org/bugzilla/show_bug.cgi?id=787 --- Additional Comments From [EMAIL PROTECTED] 2004-06-21 16:20 --- Can you try again with the next snapshot? A bug was fixed in the DRM that affected mach64 .. I want to rule it out ... -- Configure bugmail: http://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Moving forward with the TLS work
I'm getting back to the TSL work, and I'd like to wrap it up as much as possible by the end of the week. I sent a patch out of the current state of things a little bit ago. Performance testing has shown that the new dispatch functions and the old, non-thread safe dispatch functions perform equally. The difference between the two is within the error margin of the test. That's the good news. The bad news is that the combination of a multithreaded app, with an old driver, and a new libGL will result in a segfault. The code sets _glapi_Dispatch to NULL in the multithreaded case as a signal to call _glapi_get_dispatch. When the code is fully converted to TLS, the call to _glapi_get_dispatch will be replaced with a 'movl %gs:_gl_DispatchTSD, %eax' or something similar. I want to maintain compatibility across the whole matrix of old / new libGL with old / new drivers. I may be willing to sacrifice new driver + old libGL, but that's the only combination I'd be willing to give on. I think we need to do 3 things to get there: 1. Keep the old meaning of _glapi_Dispatch. This means that all the _ts_* functions and their support mechanism will have to be kept. :( However, it will only be needed for the DRI libGL. The software rendering Mesa version won't need it. 2. For non-TLS new code, implement a new variable called _glapi_DispatchTSD that implements the new behavior. There will be a weak version of that variable, that is always NULL in dri_util.c. This should allow non-TLS new code to work with old libGL binaries. 3. TLS new code can do whatever it wants. I imagine this will be a __thread variable called _glapi_tls_Dispatch or something similar. That /should/ allow support of all 4 non-TLS combinations and allow the TLS libGL to work with non-TLS drivers. However, this will defeat some of the size and linkage (prelink, etc.) benefits of the non-compatible version. I'll see if I can work something up and send out a new patch tomorrow. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 788] Display Artifacts at 1680x1050
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://freedesktop.org/bugzilla/show_bug.cgi?id=788 --- Additional Comments From [EMAIL PROTECTED] 2004-06-21 17:51 --- Created an attachment (id=402) -- (http://freedesktop.org/bugzilla/attachment.cgi?id=402action=view) Fix I committed this patch to DRI CVS to fix the problem. Thanks for the report. -- Configure bugmail: http://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 788] Display Artifacts at 1680x1050
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://freedesktop.org/bugzilla/show_bug.cgi?id=788 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-06-21 17:52 --- Fixed in DRI CVS. -- Configure bugmail: http://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
