Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
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. 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. 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/ 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. 3. A set of files similar to those in (2) implement the subset/embedded MiniGLX libGL library. They'll be in src/miniglx/ 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/. -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
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
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
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Denis Oliver Kropp ([EMAIL PROTECTED]): dri/common/ contains reusable code used by the DRI drivers while dri/common/api/ contains code to handle the drivers. dri/api/, of course. -- 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
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Keith Whitwell wrote: Hmm - I think that's a side issue to this reorg. Let's keep to code that exists - I'm not sure that everyone's communicating acurately at the moment. I think that there will probably always be some small details about the code that don't accurately map onto how the repository works, and also that talking about code is fairly error prone compared to actually working with it. Brian - I'm happy to make a start with your original layout. Lets get that up and running so that we can talk in concrete terms about any additional minor rearrangements for the final switchover. Right. So then, if anyone has anything they want to check into Mesa CVS do it soon and then be prepared to go a few days without check-ins. I don't want the repository changed while I'm working on a local copy. I may begin work this evening (around 7pm mountain time). When I begin I'll post a no more check-ins message. Just to double check we're on the same page - the new tree won't try and include the cvs history prior to this point, right? We're starting a new tree from scratch and leaving the history in the old one? Keith --- 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
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Keith Whitwell wrote: Brian Paul wrote: Keith Whitwell wrote: Hmm - I think that's a side issue to this reorg. Let's keep to code that exists - I'm not sure that everyone's communicating acurately at the moment. I think that there will probably always be some small details about the code that don't accurately map onto how the repository works, and also that talking about code is fairly error prone compared to actually working with it. Brian - I'm happy to make a start with your original layout. Lets get that up and running so that we can talk in concrete terms about any additional minor rearrangements for the final switchover. Right. So then, if anyone has anything they want to check into Mesa CVS do it soon and then be prepared to go a few days without check-ins. I don't want the repository changed while I'm working on a local copy. I may begin work this evening (around 7pm mountain time). When I begin I'll post a no more check-ins message. Just to double check we're on the same page - the new tree won't try and include the cvs history prior to this point, right? We're starting a new tree from scratch and leaving the history in the old one? No, I want to preserve file histories wherever possible in the new tree. I don't know about you, but I often look back through the CVS revisions to recall when/why things were changed. I use the SourceForge CVS browser/differencer a lot. -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
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Keith Whitwell wrote: 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. I have to admit I'm lost now. Denis is proposing a new public DRI-based API, presumably for fbdev-type environments. Suppose this API became popular and other parties wanted to implement drivers for it - drivers not based on Mesa. Is that conceivable? If so, this new interface should not be in src/mesa/ Hmm - I think that's a side issue to this reorg. Let's keep to code that exists - I'm not sure that everyone's communicating acurately at the moment. I think that there will probably always be some small details about the code that don't accurately map onto how the repository works, and also that talking about code is fairly error prone compared to actually working with it. Brian - I'm happy to make a start with your original layout. Lets get that up and running so that we can talk in concrete terms about any additional minor rearrangements for the final switchover. Keith --- 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
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Denis Oliver Kropp wrote: What do you mean by drivers not based on Mesa? ATI, for example, has Linux OpenGL drivers that use the DRI but don't use Mesa. It seems to be common misconception that the DRI was designed around Mesa, but it's not. -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
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
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
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Denis Oliver Kropp wrote: What do you mean by drivers not based on Mesa? ATI, for example, has Linux OpenGL drivers that use the DRI but don't use Mesa. It seems to be common misconception that the DRI was designed around Mesa, but it's not. Right, and the PowerVR driver as well. If we can account for DRI interfaces being used in the Mesa tree but outside of the mesa subdirectory proper, then it should be easier for IHV's to follow our changes possibly allowing for their OpenGL drivers to more easily plug into the various DRI window system bindings (GLX, mini-GLX, DirectFB futures). -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- 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
[Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Brian Paul ([EMAIL PROTECTED]): src/ mesa/ glapi/ glapi*.[ch] - dispatcher files APIspec file gl*.py - Python API scripts main/ - core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/ - was tnl t_*.[ch] X86/3Dnow code math/ - math/vector routines m_*.[ch] swrast/ - s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/ - vertex array stuff ac_*.[ch] drivers/ common/ - reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/ - OSMesa driver swfbdev/- software fbdev driver radeon/ - DRI/fbdev driver radeon-es/ - subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/ - was FX driver dos/ dri/- es dri code I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/ - reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/ - OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/ - was FX driver dos/ dri/- dri driver interface common/ - reusable driver code radeon/ - DRI/fbdev driver r200/ - DRI/fbdev driver mga/- DRI/fbdev driver -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- Convergence GmbH --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): src/ mesa/ glapi/ glapi*.[ch] - dispatcher files APIspec file gl*.py - Python API scripts main/ - core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/ - was tnl t_*.[ch] X86/3Dnow code math/ - math/vector routines m_*.[ch] swrast/ - s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/ - vertex array stuff ac_*.[ch] drivers/ common/ - reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/ - OSMesa driver swfbdev/- software fbdev driver radeon/ - DRI/fbdev driver radeon-es/ - subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/ - was FX driver dos/ dri/- es dri code Oops, dri/ is indented one tab too far, and probably not named very well. It should be probably be src/dri-es/ since it implements DRI facilities for the embedded subset. I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/ - reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/ - OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/ - was FX driver dos/ dri/- dri driver interface common/ - reusable driver code radeon/ - DRI/fbdev driver r200/ - DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. -Brian --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): src/ mesa/ glapi/ glapi*.[ch]- dispatcher files APIspec file gl*.py- Python API scripts main/- core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/- was tnl t_*.[ch] X86/3Dnow code math/- math/vector routines m_*.[ch] swrast/- s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/- vertex array stuff ac_*.[ch] drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver radeon/- DRI/fbdev driver radeon-es/- subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- es dri code Oops, dri/ is indented one tab too far, and probably not named very well. It should be probably be src/dri-es/ since it implements DRI facilities for the embedded subset. I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- dri driver interface common/- reusable driver code radeon/- DRI/fbdev driver r200/- DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet. I agree with the idea of keeping things as shallow as possible, but Denis' proposal does address the issue that I had earlier in terms of the way some of the drivers are windowsystem+drivers and some are just (dri) drivers. This way all the things in drivers/ would be equivalent objects. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. This is another worthy goal, however... Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): src/ mesa/ glapi/ glapi*.[ch]- dispatcher files APIspec file gl*.py- Python API scripts main/- core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/- was tnl t_*.[ch] X86/3Dnow code math/- math/vector routines m_*.[ch] swrast/- s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/- vertex array stuff ac_*.[ch] drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver radeon/- DRI/fbdev driver radeon-es/- subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- es dri code Oops, dri/ is indented one tab too far, and probably not named very well. It should be probably be src/dri-es/ since it implements DRI facilities for the embedded subset. I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- dri driver interface common/- reusable driver code radeon/- DRI/fbdev driver r200/- DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. Brian, One thing that would help me understand how this new tree structure (and how having the Mesa DRI driver in the tree) will work would be to understand where the resulting binary files would end up *after* a build. Specifically, can a radeon DRI driver module be built from this standalone tree? Where will it reside? Where will an embedded Mesa radeon driver module reside? and finally, future window system bindings, for example a DirectFB Mesa driver module. Where would that live? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Jens Owen wrote: Brian Paul wrote: Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): src/ mesa/ glapi/ glapi*.[ch]- dispatcher files APIspec file gl*.py- Python API scripts main/- core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/- was tnl t_*.[ch] X86/3Dnow code math/- math/vector routines m_*.[ch] swrast/- s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/- vertex array stuff ac_*.[ch] drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver radeon/- DRI/fbdev driver radeon-es/- subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- es dri code Oops, dri/ is indented one tab too far, and probably not named very well. It should be probably be src/dri-es/ since it implements DRI facilities for the embedded subset. I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- dri driver interface common/- reusable driver code radeon/- DRI/fbdev driver r200/- DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. Brian, One thing that would help me understand how this new tree structure (and how having the Mesa DRI driver in the tree) will work would be to understand where the resulting binary files would end up *after* a build. Specifically, can a radeon DRI driver module be built from this standalone tree? I don't know if that works today or not. The re-org isn't adding any new features. Keith? Where will it reside? Similar to the DRI tree, probably in drivers/dri/radeon/ Where will an embedded Mesa radeon driver module reside? Probably drivers/dri/radeon-es/ and finally, future window system bindings, for example a DirectFB Mesa driver module. Where would that live? TBD. It's really up to whoever writes the Makefile. -Brian --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Keith Whitwell wrote: Brian Paul wrote: Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): src/ mesa/ glapi/ glapi*.[ch]- dispatcher files APIspec file gl*.py- Python API scripts main/- core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/- was tnl t_*.[ch] X86/3Dnow code math/- math/vector routines m_*.[ch] swrast/- s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/- vertex array stuff ac_*.[ch] drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver radeon/- DRI/fbdev driver radeon-es/- subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- es dri code Oops, dri/ is indented one tab too far, and probably not named very well. It should be probably be src/dri-es/ since it implements DRI facilities for the embedded subset. I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- dri driver interface common/- reusable driver code radeon/- DRI/fbdev driver r200/- DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet. I agree with the idea of keeping things as shallow as possible, but Denis' proposal does address the issue that I had earlier in terms of the way some of the drivers are windowsystem+drivers and some are just (dri) drivers. I guess I still don't see how an extra directory level addresses that. This way all the things in drivers/ would be equivalent objects. I guess I don't see this either. Help me out. -Brian --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Jens Owen ([EMAIL PROTECTED]): Brian Paul wrote: Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. Brian, One thing that would help me understand how this new tree structure (and how having the Mesa DRI driver in the tree) will work would be to understand where the resulting binary files would end up *after* a build. Specifically, can a radeon DRI driver module be built from this standalone tree? Where will it reside? Where will an embedded Mesa radeon driver module reside? and finally, future window system bindings, for example a DirectFB Mesa driver module. Where would that live? There will be no DirectFB Mesa driver module. The DirectFB specific part resides in the loadable module of IDirectFBGL. This module will use the DRI driver interface from drivers/dri/, i.e. DRIMesaCreateContext etc. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- Convergence GmbH --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Brian Paul ([EMAIL PROTECTED]): Denis Oliver Kropp wrote: I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/ - reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/ - OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/ - was FX driver dos/ dri/- dri driver interface common/ - reusable driver code radeon/ - DRI/fbdev driver r200/ - DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. dri_glx.c and glxclient.h are part of XFree86 GLX/DRI AFAIK, so I think they belong into src/glx/. MiniGLX doesn't need dri_glx.c or glxclient.h. Also, extra -es versions shouldn't be needed as drivers/dri/ won't get that big and works for embedded and full driver builds. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. What about this? dri/- dri driver interface api/- public api common/ - reusable driver code radeon/ - DRI driver r200/ - DRI driver mga/- DRI driver -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- Convergence GmbH --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): Denis Oliver Kropp wrote: I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/ - reusable driver code and transform_dd/ files x11/ - X11 (XMesa) driver osmesa/ - OSMesa driver swfbdev/ - software fbdev driver windows/ beos/ ggi/ glide/ - was FX driver dos/ dri/ - dri driver interface common/ - reusable driver code radeon/ - DRI/fbdev driver r200/ - DRI/fbdev driver mga/ - DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. dri_glx.c and glxclient.h are part of XFree86 GLX/DRI AFAIK, so I think they belong into src/glx/. Last time I checked (I worked on this stuff back in November), the dri_glx.c and glxclient.h files were chopped/modified versions of what's in the XFree86/DRI tree made for the embedded subset project. That's why I was suggesting that they go into a dri-es/ directory. MiniGLX doesn't need dri_glx.c or glxclient.h. Also, extra -es versions shouldn't be needed as drivers/dri/ won't get that big and works for embedded and full driver builds. I belive that Keith put a lot of work into the radeon-es driver in order to reduce the code size for our client. Thus, I expected that code would live in a separate radeon-es/ directory. Keith? Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. What about this? 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? If you and Keith want a drivers/dri/ directory just to catagorize the DRI drivers in one place, I can live with that. -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
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): Denis Oliver Kropp wrote: I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- dri driver interface common/- reusable driver code radeon/- DRI/fbdev driver r200/- DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. dri_glx.c and glxclient.h are part of XFree86 GLX/DRI AFAIK, so I think they belong into src/glx/. Last time I checked (I worked on this stuff back in November), the dri_glx.c and glxclient.h files were chopped/modified versions of what's in the XFree86/DRI tree made for the embedded subset project. That's why I was suggesting that they go into a dri-es/ directory. MiniGLX doesn't need dri_glx.c or glxclient.h. Also, extra -es versions shouldn't be needed as drivers/dri/ won't get that big and works for embedded and full driver builds. I belive that Keith put a lot of work into the radeon-es driver in order to reduce the code size for our client. Thus, I expected that code would live in a separate radeon-es/ directory. Keith? No - the 'es' stuff is dead - it's all in the radeon/ directory and controlled by compile directives. I actually spent a bit of time scratching my head trying to figure out what 'es' meant - forgetfulness, I guess. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. What about this? 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? Keith --- 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
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
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/. 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. -- 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
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Quoting Brian Paul ([EMAIL PROTECTED]): Denis Oliver Kropp wrote: Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. What about this? 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? I just added that for all files I thought to put into drivers/dri/ to follow the guideline of files being leaves only. -- 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
