On Thu, Mar 25, 2010 at 11:22 PM, George Sapountzis <gsapount...@gmail.com> wrote: > On Thu, Mar 25, 2010 at 9:49 PM, Jakob Bornecrantz <wallbra...@gmail.com> > wrote: >> On Thu, Mar 25, 2010 at 7:00 PM, George Sapountzis >> <gsapount...@gmail.com> wrote: >>> On Thu, Mar 25, 2010 at 7:58 PM, Jakob Bornecrantz <wallbra...@gmail.com> >>> wrote: >>>> 0003 moves drisw into dri/sw and the drm dri files into dri/drm, yet >>>> again for clarity. >>>> >>>> 0004 moves the common files into a common directory. >>>> >>> >>> I think that it may be better to just consolidate dri_screen.c / >>> dri_context.c / dri_drawable.c / dri_extension.c in a single file >>> named dri.c or dri_api.c or dri_driver_api.c similar to the glx/xlib >>> state_tracker. There is not much left in the above files after >>> splitting out version-specific code. >>> >>> Then you will have: >>> dri_api.c or dri_driver_api.c for the DRI "window system" binding >>> dri_st_api.c >>> and >>> dri1.c dri2.c drisw.c for the different versions >>> >>> the only outlier is dri1_helper which I agree may have a better name. >>> >>> But then I looked at this a lot lately and your suggestion may be >>> better for someone looking at it after some time. >> >> I think you can do both, the moving of the files is more for making it >> blatantly clear what is going on. The common files live in the common >> directory and the rest are in their own directory. This mirrors what >> is done in egl. >> >> I'm ambivalent about grouping the files together. And I don't think >> that moving them it a common directory stops us from doing either one. >> Then again dri_extension.c is quite useless, and should probably be >> moved into dri_screen either way. >> >> Are you strongly against the layout that I suggested? I have no real >> problem with doing both? >> > > Ah ok, then the suggested layout serves well its purpose. Wrt to > consilidating in dri_driver_api.c (dri_util.c is effectively > dri_api.c), it depends on what your plans are for st/dri and if it > involves adding more common code, I don't have other plans for st/dri > :-)
Thanks, pushed. I don't know, I thought about trying to add EGL Image support to st/dri once it lands in st_api.h and st/egl. And thinking about it I'm leaning more towards keeping them separated. This is the traditionalist in me speaking, keeping code related to one object in each file (screen, context, drawable). This keeps things in line with the rest of the traditional dri drivers. We could merge in dri_extensions.c into dri_context.c and dri_st_api.c into dri_drawable.c and dri_screen.c, if it is the amount of files that you are worried about (in fact I prefer that over just keeping at as it is). Also I files above 1k loc board always feels a bit intimating :-). Then again this is not a strong feeling, so if you have strong opinions or it hampers your development please go ahead and change. Some improvement should be made tho. > > I'll add a comment about the ifdef's (srceen / swap_buffers in > dri_screen.c, flush_front / alloc_buffers in dri_st_api.c) and to > drisw_util.h about its relationship to dri_util.h . > >>> >>>> One thing that could be done to reduce the amount of #ifdefs would be >>>> to move the tables from dri_screen.c into drisw.c and dri2.c. >>> >>> yes, this could be done unless the suggestion above is adopted, in >>> which case I thinks it's probably better to keep all the dri_ >>> functions static and the _DriverAPI tables in the common file. >> >> There is only one function that is static that is used in the tables, >> or are you meaning that we should make them static as we move all of >> them into a single file? >> > > yes, if we move them all to dri_driver_api.c then it makes more sense > to make them static and keep _DriverAPI in dri_driver_api.c with an > ifdef. > With the -fvisibility=invisible flag given to gcc all those symbols are pretty much static. Again not strong opinions. Thanks again for the work you did. Cheers Jakob. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
