Re: Need sample program or tutorial
Fixed my problem. I was totally wrongfooted by the GLX 1.4 prescription 3.3.4 On Screen Rendering To create an onscreen rendering area, first create an X Window with a visual that corresponds to the desired GLXFBConfig, then call GLXWindow glXCreateWindow(Display *dpy, GLXFBConfig config, Window win, const int *attrib list) Indirect rendering works fine when I omit the glXCreateWindow call and use the ordinary XWindow in glXMakeCurrent(). What is the point of the glXCreateWindow function if you need a XWindow before you can call it and you can render to that XWindow already. With your help I may still learn. Enno -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Need sample program or tutorial
Bridgman, John wrote: 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. That would explain to me Jerome's earlier comment that glXIsDirect tells me all I need to know. Not sure what hardware documentation has to do with this; Documentation from source shows one way to achieve a particular goal and usually not what the chip could do to achieve a different goal or the same goal differently. Hence my preference for vendor documentation. Corbin Simpson wrote: The DRM only exposes a few simple ioctls; ... Yes but extremely powerful. They may suffer though from a similar defect as described for documentation from source - I don't know. We're already working on a project called Gallium3D, .. It's already been done with cairo-drm, which created Cairo contexts directly bound to i915 hardware through DRM. So it's certainly possible. I will have a look and also at Cairo Now, if I may, back to my immediate problem. I have a program that runs perfectly when passing False as 4th argument to glXCreateContext. glXIsDirect confirms I got an indirect rendering context. When passing True the call to glXCreateContext succeeds, glXIsDirect returns GL_TRUE but glXMakeCurrent fails. I thought and see confirmation for that thought in some of your comments that that should not happen. Correct ? Any ideas? Anyway, I will go back to the reading room. Thanks for your reactions sofar. 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
Re: Need sample program or tutorial
On Thu, 2009-05-14 at 10:35 +0200, Enno Fennema wrote: Now, if I may, back to my immediate problem. It might have been a good idea to start with that in the first place. :) I have a program that runs perfectly when passing False as 4th argument to glXCreateContext. glXIsDirect confirms I got an indirect rendering context. When passing True the call to glXCreateContext succeeds, glXIsDirect returns GL_TRUE but glXMakeCurrent fails. I thought and see confirmation for that thought in some of your comments that that should not happen. Correct ? It depends on the arguments to glXMakeCurrent. E.g. if the drawable is a pixmap, that isn't supported without DRI2. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- 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
Re: Need sample program or tutorial
Michel Dänzer wrote: It depends on the arguments to glXMakeCurrent. E.g. if the drawable is a pixmap, that isn't supported without DRI2. Good to get on a sidetrack again. You are right. XF86 does appear not to support rendering to GLXPixmaps with a direct context. But I was using an GLXWindow. How come I can succesfully get either a direct or an indirect context but with the latter glXMakeCurrent fails. I am still foxed 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
Re: Need sample program or tutorial
Just to add to my mail of a few minutes ago. I had a look at the GLX 1.4 manual and glXMakeCurrent should never return a BadValue error. I am even more foxed 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
Re: Need sample program or tutorial
On Wed, 2009-05-13 at 10:00 +0200, Enno Fennema wrote: In the absence of much activity on the user list I come for assistance here, I fail miserably in my first attempt to write a direct rendering client. I think DRI is properly installed on my system, at least glxinfo confirms Direct rendering: Yes. As a first step I just want to draw a trangle in a window. My program initializes all kind of things but when it comes to make something current I get probably confused between all contexts and windows/drawables or missed some vital step. Is there anywhere a tutorial that tells me how to write a DRI client program (not how to compile and install DRI) or a very simple program that I could have a look at. Appreciate any pointers. Enno Fennema DRI is a protocol which is here to allow X GL client to directly talk with GL driver and GL driver to talk with X to know where to render. It's not intended to be used by anyone else beyond GL driver or X server. What you want is simply a GL application and there is tons of example out there on how to do one, you could also find examples in mesa/progs/* mese/progs/trivial/tri-* for instance show how to render a simple triangle. So GL app will talk to GL driver which will use DRI on your computer if it's enabled. Cheers, Jerome Glisse -- 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
RE: Need sample program or tutorial
Couldn't DRI also be used by a non-GL direct-rendering driver, eg. for something like video acceleration ? -Original Message- From: Jerome Glisse [mailto:gli...@freedesktop.org] Sent: Wednesday, May 13, 2009 4:53 AM To: Enno Fennema Cc: dri-devel@lists.sourceforge.net Subject: Re: Need sample program or tutorial On Wed, 2009-05-13 at 10:00 +0200, Enno Fennema wrote: In the absence of much activity on the user list I come for assistance here, I fail miserably in my first attempt to write a direct rendering client. I think DRI is properly installed on my system, at least glxinfo confirms Direct rendering: Yes. As a first step I just want to draw a trangle in a window. My program initializes all kind of things but when it comes to make something current I get probably confused between all contexts and windows/drawables or missed some vital step. Is there anywhere a tutorial that tells me how to write a DRI client program (not how to compile and install DRI) or a very simple program that I could have a look at. Appreciate any pointers. Enno Fennema DRI is a protocol which is here to allow X GL client to directly talk with GL driver and GL driver to talk with X to know where to render. It's not intended to be used by anyone else beyond GL driver or X server. What you want is simply a GL application and there is tons of example out there on how to do one, you could also find examples in mesa/progs/* mese/progs/trivial/tri-* for instance show how to render a simple triangle. So GL app will talk to GL driver which will use DRI on your computer if it's enabled. Cheers, Jerome Glisse -- 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 -- 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
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
Re: Need sample program or tutorial
Enno Fennema wrote: 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. The DRM only exposes a few simple ioctls; the actual acceleration is done in Mesa. You'll need to read through the Mesa r200 code to understand what your card can and cannot do. :3 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. That sounds icky. We're already working on a project called Gallium3D, which allows us to write non-GL apps in a standardized, simple way. (Of course, unfortunately, r200 isn't planned as part of Gallium3D... :C ) 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. r200 is documented in code; check out the r200-specific parts of xf86-video-ati and Mesa for more info. 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. It's already been done with cairo-drm, which created Cairo contexts directly bound to i915 hardware through DRM. So it's certainly possible. ~ C. -- 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
RE: Need sample program or tutorial
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
