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.
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.
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?
I do very much agree with the moving out functions from u_debug into os_*.
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?
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?
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.
Cheers Jakob.
------------------------------------------------------------------------------
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
