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