On Wed, 2010-02-03 at 09:01 -0800, Brian Paul wrote: > José Fonseca wrote: > > On Wed, 2010-02-03 at 08:00 -0800, Kristian Høgsberg wrote: > >> On Wed, Feb 3, 2010 at 10:51 AM, José Fonseca <jfons...@vmware.com> wrote: > >>> On Wed, 2010-02-03 at 07:38 -0800, Kristian Høgsberg wrote: > >>>> On Wed, Feb 3, 2010 at 10:31 AM, Keith Whitwell <kei...@vmware.com> > >>>> wrote: > >>>>> Historically we had a lot of helpers in gallium/include, which have been > >>>>> incrementally moved out to gallium/auxiliary. > >>>> Is there a way we can structure the code so that the atomic operations > >>>> can be made available for core mesa (I guess I'm talking about the GL > >>>> state tracker/implementation, either way, stuff like struct > >>>> gl_framebuffer refcounts etc).? > >>> Yes. The [pu]_atomic.h header is pretty much self sufficient. If we > >>> replace the PIPE_CC_xxx by the original predefined compiler macros it > >>> would be completely self sufficient and could be shared between Mesa and > >>> Gallium. Perhaps somewhere inside mesa/include. > >>> > >>> Another possibility would be to put the compiler and os abstraction > >>> stuff in a shared component between Mesa and Gallium. Most of the stuff > >>> has the same origin anyway. It requires a bit more of playing with the > >>> build system but it's perfectly feasible, especially now that the os > >>> abstraction stuff no longer depends on other gallium auxiliary modules. > >> Either way sounds good to me - something like src/platform could work, > >> but I don't have a strong preference. I can help out if you want, but > >> it sounds like you're already moving things around so I would probably > >> just step on your toes :-) > > > > Sure! If everybody agrees with this direction then I'll get started on > > that after I'm finished with the current reorg. > > This would probably be a good move. There's a few places in the state > tracker where there's conflicts between Mesa's and Gallium's low-level > macros, etc. that could be fixed then. > > This reminds me there's a patch series from mesa3d-dev that removed a > bunch of Mesa's std C wrappers (like _mesa_memcpy()). Mabye some of > those could be applied after gallium-embedded but before the > src/platform work.
Great. It seems we have a plan then. Jose ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev