RFC: gallium-embedded

[Jose Fonseca]

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 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Jose Fonseca]

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.

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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Jakob Bornecrantz]

On Wed, Feb 3, 2010 at 12:58 PM, José Fonseca <jfonseca@...> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Jose Fonseca]

On Wed, 2010-02-03 at 07:12 -0800, Jakob Bornecrantz wrote:

> On Wed, Feb 3, 2010 at 12:58 PM, José Fonseca <jfonseca@...> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Keith Whitwell-3]

On Wed, 2010-02-03 at 07:12 -0800, Jakob Bornecrantz wrote:

> 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'm not really sure that I agree with this statement.  The inline
functions do not define the interface, they *respect* the interface.

They are convenience/utility routines and really belong with all our
other convenience/utility routines in gallium/auxiliary.

There is nothing magical about those inlines that modify, restrict, or
enable the users of the interface.  Anything done by the inline can be
done directly with the pipe_screen/pipe_context structures and there is
nothing which makes using those inlines mandatory.  

Historically we had a lot of helpers in gallium/include, which have been
incrementally moved out to gallium/auxiliary.


Keith




------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Kristian Høgsberg]

On Wed, Feb 3, 2010 at 10:31 AM, Keith Whitwell <keithw@...> 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).?

cheers,
Kristian

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Keith Whitwell-3]

On Wed, 2010-02-03 at 07:38 -0800, Kristian Høgsberg wrote:
> On Wed, Feb 3, 2010 at 10:31 AM, Keith Whitwell <keithw@...> 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).?

A lot of the aux code in mesa/src/gallium does not specifically relate
to gallium and more generally provides os/system abstractions that would
be useful to Mesa.

To date, Mesa's interactions with the gallium codebase have been
strictly limited to the mesa state tracker.  For the purposes of
rendering, I think this makes sense.

However, there's preventing us from factoring out the os-abstraction
parts of gallium (separate from anything to do with 3d, graphics or
rendering) and making them available to Mesa, which has many similar
requirements.

I'd be in favor of this anyway as it would help untangle the various
different things being achieved in the gallium/aux directory.

Keith


------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Jose Fonseca]

On Wed, 2010-02-03 at 07:38 -0800, Kristian Høgsberg wrote:
> On Wed, Feb 3, 2010 at 10:31 AM, Keith Whitwell <keithw@...> 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.

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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Kristian Høgsberg]

On Wed, Feb 3, 2010 at 10:51 AM, José Fonseca <jfonseca@...> 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 <keithw@...> 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 :-)

cheers,
Kristian

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Jose Fonseca]

On Wed, 2010-02-03 at 08:00 -0800, Kristian Høgsberg wrote:

> On Wed, Feb 3, 2010 at 10:51 AM, José Fonseca <jfonseca@...> 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 <keithw@...> 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.

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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

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 <jfonseca@...> 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 <keithw@...> 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.

-Brian

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Jose Fonseca]

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 <jfonseca@...> 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 <keithw@...> 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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Kristian Høgsberg]

On Wed, Feb 3, 2010 at 1:41 PM, José Fonseca <jfonseca@...> wrote:
...
>> 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.

What happened to the plan?   Are we going to move the header files out
to src/os or are they staying under src/gallium/auxillary/os?  Is the
idea that code under src/mesa can include the headers from
src/gallium/auxillary/os?

Kristian

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Jose Fonseca]

On Tue, 2010-02-09 at 06:37 -0800, Kristian Høgsberg wrote:

> On Wed, Feb 3, 2010 at 1:41 PM, José Fonseca <jfonseca@...> wrote:
> ...
> >> 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.
>
> What happened to the plan?   Are we going to move the header files out
> to src/os or are they staying under src/gallium/auxillary/os?  Is the
> idea that code under src/mesa can include the headers from
> src/gallium/auxillary/os?
>
> Kristian

Kristian,

Nothing happened to the plan -- I will move the header files out to
src/platform or src/os or whatever name people feel comfortable with.

But I don't have time to do it this week or likely the next.

It just not a matter of moving files -- it's also necessary to break the
dependency of the os stuff from p_config.h and p_compiler.h somehow. I
don't want gallium interfaces to depend on this new shared module nor
vice-versa. It's not very hard but getting it right needs more attention
and time than I can dispense at the moment.

If you prefer getting a start at this yourself immediately then I'm fine
with you starting a feature branch to rehearse this.

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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Kristian Høgsberg]

On Tue, Feb 9, 2010 at 9:49 AM, José Fonseca <jfonseca@...> wrote:

> On Tue, 2010-02-09 at 06:37 -0800, Kristian Høgsberg wrote:
>> On Wed, Feb 3, 2010 at 1:41 PM, José Fonseca <jfonseca@...> wrote:
>> ...
>> >> 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.
>>
>> What happened to the plan?   Are we going to move the header files out
>> to src/os or are they staying under src/gallium/auxillary/os?  Is the
>> idea that code under src/mesa can include the headers from
>> src/gallium/auxillary/os?
>>
>> Kristian
>
> Kristian,
>
> Nothing happened to the plan -- I will move the header files out to
> src/platform or src/os or whatever name people feel comfortable with.
>
> But I don't have time to do it this week or likely the next.
>
> It just not a matter of moving files -- it's also necessary to break the
> dependency of the os stuff from p_config.h and p_compiler.h somehow. I
> don't want gallium interfaces to depend on this new shared module nor
> vice-versa. It's not very hard but getting it right needs more attention
> and time than I can dispense at the moment.
>
> If you prefer getting a start at this yourself immediately then I'm fine
> with you starting a feature branch to rehearse this.

Ok, cool, I might do that, but mainly I just wanted to understand if
the plan was to leave the headers under src/gallium or move them out,
which is now clear.

thanks,
Kristian

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev