Quoting Brian Paul ([EMAIL PROTECTED]): > Denis Oliver Kropp wrote: > >Quoting Brian Paul ([EMAIL PROTECTED]): > > > >>Denis Oliver Kropp wrote: > >> > >>>Quoting Keith Whitwell ([EMAIL PROTECTED]): > >>> > >>> > >>>>Brian Paul wrote: > >>>> > >>>> > >>>>>> dri/ - dri driver interface > >>>>>> api/ - public api > >>>>>> common/ - reusable driver code > >>>>>> radeon/ - DRI driver > >>>>>> r200/ - DRI driver > >>>>>> mga/ - DRI driver > >>>>> > >>>>> > >>>>>What's the "public api"? > >>>> > >>>>Hmm, maybe the libGL code? > >>> > >>> > >>>That's the public API of DRI Mesa. It's where DRIMesaCreateContext > >>>and DRIMesaCreateDrawable etc. reside, like fxMesaCreateContext in > >>>drivers/glide/ or OSMesaCreateContext in drivers/osmesa/. > >> > >>By "DRIMesaCreateContext" do you really mean "XF86DRICreateContext"? > >>The former doesn't exist. > > > > > >I really meant DRIMesaCreateContext which doesn't exist yet, > >but will be similar to what dri_util.c currently does in the > >embedded branch. > > > >XF86 GLX/DRI should be layered on top of that. > > OK, this is news to me. I don't recall seeing anything about a new > public DRI interface.
With the tree reorg there was a discussion about making DRI windowing system independent. Along these lines I modified dri_util.c (embedded version) and the drivers to be used by MiniGLX and DirectFB, two windowing systems in terms of DRI. DirectFB applications use the dynamically loaded DirectFBGL for context creation etc. while DirectFBGL is linked against Mesa and uses the functions from dri_util.c. Until now it's just a proof-of-concept and dri_util.c looks odd, but I would like to design a public DRI interface from scratch that will be used by all windowing systems for hardware accelerated OpenGL. Sure, it's not an interface for applications in such an environment, these will use the windowing system specific API like glX, MiniGLX or DirectFBGL. > >>>MiniGLX, XF86 GLX and DirectFBGL will use this API. > >>> > >>>Even plain framebuffer device based applications could use DRI, too, > >>>e.g. SDL on the framebuffer device wouldn't need that much code to > >>>add hardware accelerated OpenGL support. > >> > >>I'm not fully aware of what's all in the embedded branches but in the > >>DRI tree: > >> > >>1. The dri_util.c code gets linked into each of the DRI driver > >>modules. It should probably go into drivers/dri/common/ > > > > > >As mentioned above dri_util.c should become the public API of DRI Mesa, > >therefore it should go into drivers/dri/api/ for now. > > I'd like to review this new API before you go too far with it. Do you > have a design doc or rough spec yet? The current state is a minimal modification of the embedded dri_util.c to proof that it's possible at all (and very well working). With these changes and the needs of GLX, MiniGLX and DirectFB in mind I want to propose and discuss a new API and driver architecture (DRI side). I don't have anything written yet. > Also, this new API probably should not be packed as libGL.so since on > Unix/X-oriented systems libGL.so is expected to support the GLX interface. After porting GLX to the new API the libGL.so would be packaged with both the new API and GLX on top of it. > >>2. The XF86DRI*() functions (which I think you alluded to) in > >>XF86dri.c get compiled into libGL. For now, XF86dri.c and all the > >>other DRI libGL files will stay in the DRI tree. > > > > > >...until they go into src/glx. > > > > > >>3. A set of files similar to those in (2) implement the > >>subset/embedded MiniGLX libGL library. They'll be in src/miniglx/ > > > > > >Right, but I want to build a libGL without MiniGLX, just with DRI. > > Do you think it will be feasible for this new DRI interface to work > with drivers not based on Mesa? If so, the code should not be in the > src/mesa/ subtree. What do you mean by "drivers not based on Mesa"? -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
