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

Reply via email to