On Wed, 2010-02-03 at 07:12 -0800, Jakob Bornecrantz wrote:
> On Wed, Feb 3, 2010 at 12:58 PM, José Fonseca <jfons...@vmware.com> wrote:
> > On Mon, 2010-02-01 at 08:31 -0800, José Fonseca wrote:
> >> I've just started another feature branch, gallium-embedded.
> >>
> >>
> >> The objectives of this branch are two-fold:
> >>
> >> - remove all inlines and os dependencies from src/gallium/include/pipe
> >> headers, so that gallium interfaces become pure interfaces and therefore
> >> everything else becomes optional
> >>
> >> - move all OS abstractions to a separate optional module so that porting
> >> to new platforms is easier -- there will be a clear list of functions
> >> that need to be implemented
> >>
> >>
> >> The only planned interface change is pipe_reference -- it will be
> >> reduced to an ordinary int32_t -- which is key to achieve the above.
> >> Implementations of gallium should use p_atomic or their version of
> >> atomic operations. For platforms without hardware-support atomic
> >> operations (I personally don't know any interesting platform that fits
> >> the profile) gallium will either be single threaded or a global mutex
> >> should be acquired before incrementing refcounts.
> >>
> >>
> >> In summary there will be three levels of integration with gallium:
> >>
> >> 1 - just the gallium interfaces, mean and lean
> >>
> >> 2 - gallium interfaces and auxiliary modules but no OS abstractions
> >> (e.g. for embedded platforms)
> >>
> >> 3 - everything (interfaces + auxiliary + os abstractions). all existing
> >> platforms (linux, windows, etc)
> >>
> >>
> >> If there are any concerns with this direction please let me know as soon
> >> as possible.
> >>
> >>
> >> Jose
> >
> > The branch is ready for merge.
> >
> > There are no gallium interface per se, just shuffling stuff around. The
> > interesting bits are:
> >
> > -
> > http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/os?h=gallium-embedded
> > -
> > http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe?h=gallium-embedded
> >
> > git diff --diff-filter=M
> > 5cc20a06b05bd551b663c050fb4802e2658decd5..origin/gallium-embedded --
> > src/gallium/include/pipe/
> >
> > Let me know there are objections/suggestionns.
>
> First of some of the commits are confusing in particularly "gallium:
> Make pipe_atomic a regular int32_t." since there are '#include
> "u_debug.h"' sprinkled all over the place. In previous commits you
> handled this much better.
Fair enough. I'll take more care next time.
> Further on the topic of that commit I don't agree with removing the
> pipe_atomic stuff from the gallium interface, the reference counting
> is apart of the interface and it must be the same across a platform.
> If you where to define a different platform it could change, but just
> as you need to add support to a platform in the p_config and
> p_compiler files you need to add support for p_atomic. In short I
> think you set the bar just a tad bit to low and the interface got hurt
> in the process.
The atomic operations semantics are quite clear. Two different
implementations can perfectly inter-operate if they follow the
semantics.
> Also the removal of some of the inlines seems a bit to harsh as well,
> the pipe_buffer_{unmap|map} inlines for instance holds a bit of
> semantics in them. In short about this and the p_atomic functions, I
> view them as apart of the interface just as much as pipe_context. Is
> there a particularly reason for removing the inlines? Portability or
> just general dislike of them?
Portability. Not dislike. Inlines depend on asserts which depend on
auxiliary modules, therefore it violates the goal of being able to use
gallium without auxiliary modules.
The inlines are really short cuts, and their semantics are either
implementation details or derive from gallium interface semantics.
> I do very much agree with the moving out functions from u_debug into os_*.
I'm glad you liked something!! :D
> You might want to protect the PIPE_OS_* defines with "#ifndef
> PIPE_OS_EMBEDDED" so that you don't end up with more then one
> platform. Or is PIPE_OS_EMBEDDED meant to be a subsystem thing?
Yep. That will happen soon. The branch is just for the invasive
refactoring changes. The remaining embedded platform specific stuff can
be done incrementally on master without disruption.
> And this is not a comment about your work but more of a legacy thing,
> p_config.h defines PIPE_CC_* shouldn't those be defined inside of
> p_compiler.h?
Yeah, they could.
> And the final bit, can you please update the documentation before
> merging. Information about where the different PIPE_* defines are
> defined. List of symbols that should be exposed by the os_ files. How
> you go about adding a new platform would be nice but might be a bit to
> much.
os module is not a gallium interface. Auxiliary stuff is optional and it
is not gallium on the strict sense -- just a possible implementation of
it.
There was never the commitment to document every auxiliary module.
I'll add a brief mention of OS module to gallium-docs if that's what
you're asking.
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
