My understanding was that XF86DRIQueryDirectRenderingCapable just asked the X server if *it* was able to support direct rendering on a particular screen, didn't tell you anything about whether the right 3D driver existed or was installed correctly.
I think the convention is to ask for direct when creating a context unless you have a good reason for needing indirect (eg some compositing managers need to use indirect), then if you care you can use glXIsDirect to see if you got it. The DRI API is for inter-driver communication only AFAIK, not for application use. Not sure what hardware documentation has to do with this; pretty much everything in the original R200 documentation (I'm guessing that's what you're referring to, since there is a lot of publicly available documentation for newer chips) has been transcribed into the open source drivers already. In terms of the relationship, I thought it was basically : - app calls GL lib - GL lib uses DRI to see if server supports direct rendering for that screen - if yes, GL lib makes other calls to set up shared areas and find name of 3d driver - if all that succeeds, GL lib passes drawing calls directly to the 3d driver AIGLX is more complicated but not a lot more so. Anyways, bottom line is that if you are writing another direct rendering driver you probably should be using DRI calls and if you are not writing a driver then you probably should just be using GLX calls... or something like that ;) -----Original Message----- From: Enno Fennema [mailto:e.fenn...@tiscali.nl] Sent: Wednesday, May 13, 2009 3:57 PM To: Jerome Glisse; Bridgman, John Cc: dri-devel@lists.sourceforge.net Subject: Re: Need sample program or tutorial Jerome Glisse wrote: ... > Why do you want to use XF86DRIQueryDirectRenderingCapable ? I only called XF86...Capable to confirm that the software recognized my video card as *capable* of direct rendering. > glXIsDirect tells you what you want to know ie if it's direct or not. Correct, glXDirect tells me the context is or is not *using* direct rendering. > I don't understand what you are trying to do here, you shouldn't care > to know if direct rendering is enabled or not, applications shouldn't > behave differently if DRI is enabled or not. I thought direct rendering is faster than indirect as it avoids the translation from OpenGL to the X protocol and then back again. The difference in application behaviour is then only speed but it my case the difference is 'crash' or 'works ok'. Another question is why should I specify direct/indirect in glXCreateContext if there is no reason to care. My longer term aim is to understand what my Radeon SE9200 can and cannot do. Mesa is so clever that it hides by software when hardware is deficient. I think that only by getting access to the the drm kernel driver can I start exploring the hardware. As John Bridgman wrote DRI might be useful too for non-GL applications, which do want contact with the X server not to clobber other windows but otherwise would like to access non-GL capabilities of the hardware or GL capabilities in a differnt way. Radeon documentation is possibly available but under non disclosure conditions which I do not want to accept. At least I found very little publicly available. In the short run I try to understand a bit better how DRI manages the relation ships between X windows, those that GLXWindows and, maybe an impossible animal, a DRM Window, which shows consideration for other X windows. Regards, Enno ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
