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.

> Let's clarify what's meant by public.  I consider a public interface 
> one that's directly used by application programs.  The 
> XF86DRICreateContext() and related functions are never used by 
> applications.  They're used by libGL and the DRI drivers.
> 
> fxMesaCreateContext() and OSMesaCreateContext() really are public 
> interface functions.

That's what I thought, fxMesaCreateContext(), OSMesaCreateContext(),
DRIMesaCreateContext() etc.

> >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.

> 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.

> So, my suggestion is that the src/mesa/drivers/dri/api/ directory 
> isn't really needed; those files should go in 
> src/mesa/drivers/dri/common/.  And, all the files which get compiled 
> into the MiniGLX libGL should be in src/miniglx/.

dri/common/ contains reusable code used by the DRI drivers
while dri/common/api/ contains code to handle the drivers.

-- 
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

Reply via email to