Re: [Dri-devel] problems with CVS head and i810
Dave Airlie wrote: Which application is this? my own internal application (it doesn't do much just some quad texture mapping (About 20 quads on screen). Would it be possible to see the source? If not, can you make a little demo that does something similar and has the same problems that you can post? Keith --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] i810 cleanup
On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote: The 830 page flipping code is turned off for some good reasons: - I haven't seen it work without really visible corruption on the flip - typically flashing and blank areas Presumably it uses the mi shadow module, and you should try shadowfb instead? Have you (or anyone else, for that matter) had a chance to try my patch for the radeon driver? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] i810 cleanup
Michel Dänzer wrote: On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote: The 830 page flipping code is turned off for some good reasons: - I haven't seen it work without really visible corruption on the flip - typically flashing and blank areas Presumably it uses the mi shadow module, and you should try shadowfb instead? Have you (or anyone else, for that matter) had a chance to try my patch for the radeon driver? I haven't. I'll have to go back to the last email thread I had on this, with Alan Hourihane, where (I think) I convinced myself once again that there was no way any copying scheme could ever be completely correct, and that only double-drawing could do the job properly. However, that's not the problem with the i830 - I mean hardware flashes, image breakup, etc on the flip. Keith --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] i810 cleanup
Michel Dänzer wrote: On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote: Michel Dänzer wrote: On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote: The 830 page flipping code is turned off for some good reasons: - I haven't seen it work without really visible corruption on the flip - typically flashing and blank areas Presumably it uses the mi shadow module, and you should try shadowfb instead? Have you (or anyone else, for that matter) had a chance to try my patch for the radeon driver? I haven't. I'll have to go back to the last email thread I had on this, with Alan Hourihane, where (I think) I convinced myself once again that there was no way any copying scheme could ever be completely correct, and that only double-drawing could do the job properly. I on the other hand am pretty convinced that double drawing will never work. :) Because it doesn't handle unaccelerated primitives, or how does it? You have to double draw everything. I don't have an implementation, but a correct one would do those twice, too. Keith --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] i810 cleanup
Michel Dänzer wrote: On Mon, 2002-12-16 at 13:47, Keith Whitwell wrote: Michel Dänzer wrote: On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote: Michel Dänzer wrote: On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote: The 830 page flipping code is turned off for some good reasons: - I haven't seen it work without really visible corruption on the flip - typically flashing and blank areas Presumably it uses the mi shadow module, and you should try shadowfb instead? Have you (or anyone else, for that matter) had a chance to try my patch for the radeon driver? I haven't. I'll have to go back to the last email thread I had on this, with Alan Hourihane, where (I think) I convinced myself once again that there was no way any copying scheme could ever be completely correct, and that only double-drawing could do the job properly. I on the other hand am pretty convinced that double drawing will never work. :) Because it doesn't handle unaccelerated primitives, or how does it? You have to double draw everything. I don't have an implementation, but a correct one would do those twice, too. And how is drawing things twice different to drawing them once and then copying? The problem with the mi shadow module is that the copy doesn't happen immediately after drawing. I think maybe I decided copying was ok as long as: - you rig XAA (or whatever) to always draw into the current front buffer. - you use cliprects to exclude the 3d window so that the backbuffer never gets scribbled. I don't see what difference it makes when the copy happens -- I think the current shadow module implementation is fine for that. Keith --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] i810 cleanup
Michel Dänzer wrote: On Mon, 2002-12-16 at 14:04, Keith Whitwell wrote: I think maybe I decided copying was ok as long as: - you rig XAA (or whatever) to always draw into the current front buffer. - you use cliprects to exclude the 3d window so that the backbuffer never gets scribbled. Right, I keep forgetting about the issues involved with mixing X11 and OpenGL. If we exclude the 3D window, it doesn't matter which buffer is drawn to though, or am I missing something again? It matters because then you'd only see the results when X and GL agree on which one is the front buffer... I don't see what difference it makes when the copy happens -- I think the current shadow module implementation is fine for that. For one, there can be no copy between to flips... Oh yes, that's a good point. Keith --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI/DRM/stuff overview?
On Sat, Dec 14, 2002 at 09:42:58AM +0300, Samium Gromoff wrote: There is one hopefully nice idea to help DRI developement. The first and best thing to make a project successful is a good and clean codebase. The second is a comprehensible set of docs in order to attract more developers. I agree these two points are very important indeed. I think that the DRI codebase could use a few more comments and has some redundancies which are very difficult to factor them out due to all the different driver peculiarities, but besides that is actually very clean and easy to read considering its size. Documentation to attract more developers was one of the main reasons why I compiled and wrote the DRI Developers' FAQ: http://dri.sourceforge.net/doc/faq/ . Not that i have paid enough time to find anything, but i think that a dia overview diagram of the overall structure/APIs would be extremely nice. e.g. how XFree talks to DRM, what DRMs are supposed to provide, DMA issues etc etc also examples could be very useful indeed... There are already some very good diagrams on http://dri.sourceforge.net/doc and I hope that someday that the DRI Driver HOWTO, http://dri.sourceforge.net/doc/howto/ , will give the examples you want, but it's still in early stages. Please feel free to contribute to any of these [in the wide sense] documentation projects. Regards, José Fonseca __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] S3 Drivers
I an extrimely intrested in developing DRI for S3 ProSavage DDR(and ready to participate in development). SoI wanted to ask: 1)Is anybody developing(or already developed) such drivers . 2)If no, where from can i take information on my chipsets system of commands(Is disassembling of windows driver the only way to get it?) Thank you, Rudnev Alexey [EMAIL PROTECTED].
Re: [Dri-devel] Mesa version and Radeon driver
On Mon, 2002-12-16 at 18:07, Martin Spott wrote: Unfortunately my mail got lost last weekend, so I hope you forgive me this repost. I made three screenshots showing FlightGear on the default start position. My aim is to convince people of the advantages of the current DRI CVS trunk. XFree86-4.2 - as shipped with SuSE-8.1: http://document.ihg.uni-duisburg.de/bitmap/Radeon/XFree86-4.2.png DRI 'trunk': http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-5.x.png DRI with Mesa-4.0.4 - as suggested for shipping with XFree86-4.3: http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4.png Is the 4.0.4 screenshot from after I merged fixes from the trunk? I _vote_ for Mesa-5.x - as you may imagine :-) Well, it doesn't look that much better, does it? Do you really think it's worth rushing in Mesa 5 for that? Sure, the 'old' code has problems, but at least it's well tested with all drivers. You can always use DRI CVS or 4.2.0 if that suits you better. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa/DRI version for XFree86 4.3
On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel Dänzer wrote: On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/ Changes by: mdaenzer@sc8-pr-cvs1. 02/12/14 09:42:48 Log message: merge changes from trunk since Mesa 5.0 merge Okay, I think that should fix the most pressing issues people think were fixed by the Mesa 5.0 merge. Thanks for doing that! I've taken that and merged it into the XFree86 trunk. I've also merged the XFree86 trunk back into mesa-4-0-4-branch, but I'm not having much success in committing it. My first commit attempt aborted, then I couldn't connect to the CVS repository for a while, then trying again just now it's failing because there are various locks in the repository from the first aborted attempt. Anyway, the pre-merge tag is mesa-4-0-4-20021214 and when I can finally finish committing the merge, the post-merge tag will be mesa-4-0-4-20021215. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Re: [Dri-devel] Radeon x86 PCI [Was: help selecting a graphics card, and some general questions]
Third'ed belatedly... one of my friends just got an A7N266-VM and has a Sapphire Radeon 7500, so without this code being activated (by recompile) he can't use DRI... thankfully we can do that, but it'd be nice to have it in XFree 4.3.0. - Chad On Thu, 5 Dec 2002, [iso-8859-15] José Fonseca wrote: I'll second Keith Gross here: we should enable PCI support even if there are situations were it can cause problems, as the situations can be avoided with proper configuration and more people could enjoy DRI. After all, we strive to add functionality to the drivers, not to hide it from users, and it's not the case here in my POV. José Fonseca On Wed, Dec 04, 2002 at 05:30:44PM +, Keith Gross wrote: Might it not be possible to eliminate all the PCIGART_ENABLED stuff and for the time being control this in the XF86Config. If you have a PCI card you use ForcePCIMode true. If you have a AGP card you use either ForcePCIMode false or just say nothing and the driver assumes AGP. This way the PCI GART gets more testing and a lot of people like me don't spend many frustating hours figuring out that PCI Radeons are not supported by default and than having to build their own to get it working. __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa version and Radeon driver
On Mon, Dec 16, 2002 at 06:44:46PM +0100, Michel Dänzer wrote: DRI with Mesa-4.0.4 - as suggested for shipping with XFree86-4.3: http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4.png Is the 4.0.4 screenshot from after I merged fixes from the trunk? I believe so. The screenshot dates on 2002-12-13 18:04 (CET) and the CVS update was taken very few hours before. I must admit that I was a bit lazy today so I didn't want to retype the whole message so I'd add something here. The most interesting thing (for _me_) is the evidence, that the picture does _not_ differ dependent on the X server I use. I can throw in different X server binaries, but the real difference becomes obvious when I change the underlying OpenGL libraries - wether they com from SuSE-8.1, from DRI/Mesa-4.0.4 or from DRI/Mesa/5.x This implies - as I understand the topic - that the Mesa libraries have far the most influence on what the user looks at. Well, it doesn't look that much better, does it? Do you really think it's worth rushing in Mesa 5 for that? To be honest, the branch with Mesa-4.0.4 is currently not worth talking about when it comes to using FlightGear. I built a _lot_ of DRI (Mesa-4.x) trees during the past months to have the impression that improvement is unlikely to happen here. So Mesa-5.x appears to be the big step that promises - for me - an XFree86 release that I would count on. Sure, the 'old' code has problems, but at least it's well tested with all drivers. You can always use DRI CVS or 4.2.0 if that suits you better. If the user had to consider XFree86-4.3 as 'broken' because of non functional OpenGL support, so why should people use it ? These are disproportionate strong words, but I believe the 'user' will think this way once he has the decision to make, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa version and Radeon driver
Am Montag, 16. Dezember 2002 20:29 schrieb Martin Spott: On Mon, Dec 16, 2002 at 06:49:26PM +0100, Dieter Nützel wrote: http://document.ihg.uni-duisburg.de/bitmap/Radeon/Mesa-4.0.4.png None if these links works. Sorry, the University appears to have network trouble this evening, Solved, works now. Thanks, Dieter --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 notes issues
Keith Whitwell wrote: Andy Ross wrote: Is it possible [...] to get the client-side libGL to look somethere *other* that /usr/X11R6/lib/modules/dri for drivers? It's LIBGL_DRIVERS_PATH Perfect. Thanks. You also don't exhibit a texture border bug that the ATI drivers have We fallback on some texture border cases. Not this one, I suspect. The runway markings are built up of tiled quads, drawing the whole texture into each quad. This makes up probably 20-30% of the screen pixels at startup; if you were rendering them in software I'm sure it would be noticeable. Actually, I'm fuzzy on the spec here. The DRI (and NVidia) drivers appear to *not* sample the texture border color by default when drawing quads with texture coordinates of exactly 1 and 0. The ATI ones seem to do so, which results in a dark stripe between tiles (FlightGear doesn't bother to set the border color and leaves it as black). Problem is, my cursory reading of the spec says that ATI is right and the rest of the world (!) is wrong, even though that would make life hell for people who simply want to build up tiled images and don't care (much) about border artifacts. What's the truth? There are sporadic rendering bugs in FlightGear, however. Every ~40 frames or so, I'll see a large triangle or two flash on the screen. How recent is this driver? I fixed some problems like that a week or two ago. It's CVS from the trunk as of yestserday afternoon. Should I be using a different branch? I'm also seeing some stability trouble in FlightGear. These sorts of bugs are basically impossible to debug remotely. Unless you're willing to dig into the driver yourself, or at least figure out a way to easily reproduce the problem in a (much) less complicated program than flightgear, or convince someone to spend *a lot* of time working through it with you, it won't get fixed. Try and narrow the behaviour down. Yeah, this was mostly a shot in the dark. I was hoping someone could chime in with a note like you need to enable the whizgig when running on your hardware version or check the foozle to see what lock the server is waiting on, etc... I'll take a closer look. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 notes issues
Andy Ross wrote: Keith Whitwell wrote: Andy Ross wrote: Is it possible [...] to get the client-side libGL to look somethere *other* that /usr/X11R6/lib/modules/dri for drivers? It's LIBGL_DRIVERS_PATH Perfect. Thanks. You also don't exhibit a texture border bug that the ATI drivers have We fallback on some texture border cases. Not this one, I suspect. The runway markings are built up of tiled quads, drawing the whole texture into each quad. This makes up probably 20-30% of the screen pixels at startup; if you were rendering them in software I'm sure it would be noticeable. Actually, I'm fuzzy on the spec here. The DRI (and NVidia) drivers appear to *not* sample the texture border color by default when drawing quads with texture coordinates of exactly 1 and 0. The ATI ones seem to do so, which results in a dark stripe between tiles (FlightGear doesn't bother to set the border color and leaves it as black). Problem is, my cursory reading of the spec says that ATI is right and the rest of the world (!) is wrong, even though that would make life hell for people who simply want to build up tiled images and don't care (much) about border artifacts. What's the truth? Texture borders are kinda complicated. You can either define an explicit image border (glTexImage2D's border=1) or use the default texture border color. Whether or not the texture border is sampled is determined by the texture filter and wrap mode. There are lots of mode combinations, some of which sometimes sample the border, and others which never do. Texture borders are an area that's still kind of flakey in today's drivers. They've always been trouble. I've been pretty careful to get this right in Mesa's software rasterizer. The Mesa/test/texwrap.c demo shows a bunch of different modes. There are sporadic rendering bugs in FlightGear, however. Every ~40 frames or so, I'll see a large triangle or two flash on the screen. How recent is this driver? I fixed some problems like that a week or two ago. It's CVS from the trunk as of yestserday afternoon. Should I be using a different branch? I'm also seeing some stability trouble in FlightGear. These sorts of bugs are basically impossible to debug remotely. Unless you're willing to dig into the driver yourself, or at least figure out a way to easily reproduce the problem in a (much) less complicated program than flightgear, or convince someone to spend *a lot* of time working through it with you, it won't get fixed. Try and narrow the behaviour down. Yeah, this was mostly a shot in the dark. I was hoping someone could chime in with a note like you need to enable the whizgig when running on your hardware version or check the foozle to see what lock the server is waiting on, etc... I'll take a closer look. Andy -Brian --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa version and Radeon driver
On Mon, Dec 16, 2002 at 10:01:18PM +0100, Michel Dänzer wrote: On Mon, 2002-12-16 at 20:52, Martin Spott wrote: O.k, I'll do a rebuild this evening - although I might not be able to verify a screenshot before tomorrow, Hmmm - unfortunately, after (I think) David's unsuccessfull merge attempts, the 4.0.4-branch does not build: radeon_ioctl.c:44:46: radeon_macros.h: No such file or directory make[5]: *** [radeon_ioctl.o] Error 1 make[5]: Leaving directory /opt/tmp/DRI/lib/GL/mesa/src/drv/radeon' I don't have the time tonight to look after this :-( David's merge may still be in progress, update from CVS tomorrow and try again. It's done now. I had my local copy done and building last night, but it took most of today to get the actual commits and tag done. The DRI CVS server seemed very slow/flaky today. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa/DRI version for XFree86 4.3
On Die, 2002-12-17 at 02:53, David Dawes wrote: I don't know the story behind the removal of RADEONSaveFBDevRegisters() -- seems to be related to keeping pageflipping working over an fbdev call. Can anyone comment on whether or not this is still necessary? I expect that got accidentally removed. I'm also not sure if the handling of gen_int_cntl is correct everywhere. The attached patch should put back most of what got inadvertently removed. Yes, looks good to me, thanks. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] i810 cleanup
Well the i830 page flip code is using async flips, the main thing I want to use page flipping for on my i815 is sync'ed flips so I don't see the tearing that is so really obvious and gives people headaches.. (don't need to be getting sued here!!). It's not the timing I'm worried about it's the tearing, it can be slow as long as its not really ugly... the i815 can't do async page flipping properly anyways there is a bug in the silicon I would assume they fixed it for the i830 ... Also my current application is a single 3D window taking up the full screen, I doubt I'll ever any 2d windows interfering which is handy for me... My major issue now is finding a CVS tree which works for me on my development platform that I can then add code to. As my patch doesn't affect anything other than cleanup can you check it in? Dave. The 830 page flipping code is turned off for some good reasons: - I haven't seen it work without really visible corruption on the flip - typically flashing and blank areas - It isn't actually all that fast - there is a delay while (presumably) the ramdac cache or fifo drains - this is comparable to the time to blit the window itself. The crossover point was about 300x300 on my test box, but would vary for different machines. - Because of the above, it is necessary to wait for the flip to finish before clearing the backbuffer starting the next frame, otherwise you see this happen. Actually this invalidates my explanation of the delay -- the fact that you can see the clear implies that the ramdac is still grabbing new values from the frontbuffer, so I don't really know what the delay arises from. Keith -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
