Mesa release for the end of March?

[Ian Romanick-4]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

It's time again to plan what version or versions of Mesa we want to
release in Q1 (end of March).  It seems like 7.7.1 is a no-brainer.  Do
we also want to release Mesa 7.8?  I haven't been keeping track of
master, so I don't know what its state is.  Is it pretty stable?  Are
there any big branches waiting to land?

Working backwards from a "last week of March" release, master would have
to branch to mesa_7_8_branch during the last week of February.  That's
roughly 6 weeks away.

Thoughts?  Opinions?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktOFlcACgkQX1gOwKyEAw/P2QCfRWx/u2sTv2ydAX1JYRROrEM3
YGsAn27ykDyldakkW6E/6L33oyCYjmMB
=abh7
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

Ian Romanick wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> It's time again to plan what version or versions of Mesa we want to
> release in Q1 (end of March).  It seems like 7.7.1 is a no-brainer.  Do
> we also want to release Mesa 7.8?  I haven't been keeping track of
> master, so I don't know what its state is.  Is it pretty stable?  Are
> there any big branches waiting to land?

Master seems pretty stable now and I think a 7.8 release would be OK
but there are a few semi-major things coming in:

1. A lot of EGL and OpenGL ES changes.

2. I have an outstanding branch that cleans up some texture image code
related to mapping/unmapping that I'd like to get merged but it could
break some things.  I'll try to get back on that one of these days.

3. Ongoing enhancements to gallium to support GL3.  That's being done
step-by-step and shouldn't cause much upheaval.  We can probably put a
stake in the ground at any time for 7.8.

BTW, when we do get GL3 support we'll bump Mesa to 8.0 but there's no
target date yet.


> Working backwards from a "last week of March" release, master would have
> to branch to mesa_7_8_branch during the last week of February.  That's
> roughly 6 weeks away.
>
> Thoughts?  Opinions?

Sounds OK to me.

-Brian

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Corbin Simpson]

Sometime over the next day I will update the docs and flesh out the gallium info. R300g should be marked as testing; it passes roughly as much piglit as softpipe.

I would only recommend blocking 7.8 to get those gallium docs filled out; otherwise, no complaints here.

Posting from a mobile, pardon my terseness. ~ C.

On Jan 13, 2010 2:43 PM, "Brian Paul" <brianp@...> wrote:

Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All, > > It's time again...

Master seems pretty stable now and I think a 7.8 release would be OK
but there are a few semi-major things coming in:

1. A lot of EGL and OpenGL ES changes.

2. I have an outstanding branch that cleans up some texture image code
related to mapping/unmapping that I'd like to get merged but it could
break some things.  I'll try to get back on that one of these days.

3. Ongoing enhancements to gallium to support GL3.  That's being done
step-by-step and shouldn't cause much upheaval.  We can probably put a
stake in the ground at any time for 7.8.

BTW, when we do get GL3 support we'll bump Mesa to 8.0 but there's no
target date yet.

> Working backwards from a "last week of March" release, master would have > to branch to mesa_7_8...

Sounds OK to me.

-Brian

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev

_______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@......

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Chia-I Wu-2]

On Thu, Jan 14, 2010 at 2:52 AM, Ian Romanick <idr@...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> It's time again to plan what version or versions of Mesa we want to
> release in Q1 (end of March).  It seems like 7.7.1 is a no-brainer.  Do
> we also want to release Mesa 7.8?  I haven't been keeping track of
> master, so I don't know what its state is.  Is it pretty stable?  Are
> there any big branches waiting to land?
I plan to merge opengl-es-v2 and finish EGL cleanup work before February.  The
EGL work is outlined in another thread, and if it comes to a conclusion soon
(it seems likely so far), it takes only a few days to finish.

As for opengl-es-v2, I will send a status update and my merge plan to the list
tomorrow.  IMO, it is ready.  As it is quite self-contained, I don't think it
will introduce any regression.  The most significant change to existing code is
in glapi.  I might need your help here.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Ian Romanick-4]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Romanick wrote:

> All,
>
> It's time again to plan what version or versions of Mesa we want to
> release in Q1 (end of March).  It seems like 7.7.1 is a no-brainer.  Do
> we also want to release Mesa 7.8?  I haven't been keeping track of
> master, so I don't know what its state is.  Is it pretty stable?  Are
> there any big branches waiting to land?
>
> Working backwards from a "last week of March" release, master would have
> to branch to mesa_7_8_branch during the last week of February.  That's
> roughly 6 weeks away.
>
> Thoughts?  Opinions?

Assuming this plan still works for people, I'll make the mesa_7_8_branch
on Friday, February 26th.

Since we're not using CVS, would it be possible to start naming the
release branches with just the release version?  Likewise for release
tags?  Specifically, I'm proposing to use 7.8 for this next branch and
7.8.0 for the release tag.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt8QQwACgkQX1gOwKyEAw9+ogCfYidwtsyMKVk0dwDSNxsGEBef
mn0AniNACJ113prQA/dBw14EyiF5W/nF
=shtQ
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[tom fogal-3]

Ian Romanick <idr@...> writes:
> Since we're not using CVS, would it be possible to start naming the
> release branches with just the release version?  Likewise for release
> tags?  Specifically, I'm proposing to use 7.8 for this next branch
> and 7.8.0 for the release tag.

+1.  It's a pain to type out the full name all the time ;)

-tom

------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

tom fogal wrote:
> Ian Romanick <idr@...> writes:
>> Since we're not using CVS, would it be possible to start naming the
>> release branches with just the release version?  Likewise for release
>> tags?  Specifically, I'm proposing to use 7.8 for this next branch
>> and 7.8.0 for the release tag.
>
> +1.  It's a pain to type out the full name all the time ;)

I like keeping things consistent but this change would be OK.

-Brian


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-3]

Ian Romanick wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ian Romanick wrote:
>> All,
>>
>> It's time again to plan what version or versions of Mesa we want to
>> release in Q1 (end of March).  It seems like 7.7.1 is a no-brainer.  Do
>> we also want to release Mesa 7.8?  I haven't been keeping track of
>> master, so I don't know what its state is.  Is it pretty stable?  Are
>> there any big branches waiting to land?
>>
>> Working backwards from a "last week of March" release, master would have
>> to branch to mesa_7_8_branch during the last week of February.  That's
>> roughly 6 weeks away.
>>
>> Thoughts?  Opinions?
>
> Assuming this plan still works for people, I'll make the mesa_7_8_branch
> on Friday, February 26th.

I think we could get by with a shorter "beta" period.  There's a few
more things that would be nice to do for 7.8 which I doubt I'd get to
before the 26th:

1. GL_APPLE_object_purgeable - I think the last round of patches
looked OK.  Chris?

2. _mesa_memcpy() -> memcpy(), etc. replacement.  There were patches
for this that haven't been applied yet.  Maybe someone could pick
those up.

3. I'm tempted to remove some old Mesa drivers such as glide, tdfx,
allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?

-Brian

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Chia-I Wu-2]

On Fri, Feb 19, 2010 at 8:25 AM, Brian Paul <brianp@...> wrote:

>> Assuming this plan still works for people, I'll make the mesa_7_8_branch
>> on Friday, February 26th.
> I think we could get by with a shorter "beta" period.  There's a few
> more things that would be nice to do for 7.8 which I doubt I'd get to
> before the 26th:
> 1. GL_APPLE_object_purgeable - I think the last round of patches
> looked OK.  Chris?
> 2. _mesa_memcpy() -> memcpy(), etc. replacement.  There were patches
> for this that haven't been applied yet.  Maybe someone could pick
> those up.
> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx,
> allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?

I like this change.

There are some Makefiles under src/mesa/main/.  Are they still used?  Could we
remove them?

--
olv@...

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[George Sapountzis]

On Fri, Feb 19, 2010 at 2:25 AM, Brian Paul <brianp@...> wrote:
>
> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx,
> allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?
>

- dri/fb (superceded by swrast ?)
- dri/ffb (drm dropped years ago ?)

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Kristian Høgsberg]

On Thu, Feb 18, 2010 at 7:25 PM, Brian Paul <brianp@...> wrote:

> Ian Romanick wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Ian Romanick wrote:
>>> All,
>>>
>>> It's time again to plan what version or versions of Mesa we want to
>>> release in Q1 (end of March).  It seems like 7.7.1 is a no-brainer.  Do
>>> we also want to release Mesa 7.8?  I haven't been keeping track of
>>> master, so I don't know what its state is.  Is it pretty stable?  Are
>>> there any big branches waiting to land?
>>>
>>> Working backwards from a "last week of March" release, master would have
>>> to branch to mesa_7_8_branch during the last week of February.  That's
>>> roughly 6 weeks away.
>>>
>>> Thoughts?  Opinions?
>>
>> Assuming this plan still works for people, I'll make the mesa_7_8_branch
>> on Friday, February 26th.
>
> I think we could get by with a shorter "beta" period.  There's a few
> more things that would be nice to do for 7.8 which I doubt I'd get to
> before the 26th:
>
> 1. GL_APPLE_object_purgeable - I think the last round of patches
> looked OK.  Chris?
>
> 2. _mesa_memcpy() -> memcpy(), etc. replacement.  There were patches
> for this that haven't been applied yet.  Maybe someone could pick
> those up.

I applied the patches from Kenneth Graunke on the list for this.  Can
we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
_mesa_bzero() too?  What about the _mesa_*printf() functions?  It
looks to me like they just wrap the platform *printf() functions and
don't provide any fallbacks if the platform doesn't provide the
function.

> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx,
> allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?

Sounds great.  As George suggests, maybe we can drop dri/fb and
dri/ffb too?  What about d3d?  I don't know much about the driver, but
I don't see a lot of commits there since 1999 except mechanical
changes to keep it compiling.

Finally, I'd like to land EGLImage support for the dri2 EGL driver,
which I should be able to do next week.

thanks,
Kristian

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-4]

On Thu, Feb 18, 2010 at 9:50 PM, Chia-I Wu <olvaffe@...> wrote:

> On Fri, Feb 19, 2010 at 8:25 AM, Brian Paul <brianp@...> wrote:
>>> Assuming this plan still works for people, I'll make the mesa_7_8_branch
>>> on Friday, February 26th.
>> I think we could get by with a shorter "beta" period.  There's a few
>> more things that would be nice to do for 7.8 which I doubt I'd get to
>> before the 26th:
>> 1. GL_APPLE_object_purgeable - I think the last round of patches
>> looked OK.  Chris?
>> 2. _mesa_memcpy() -> memcpy(), etc. replacement.  There were patches
>> for this that haven't been applied yet.  Maybe someone could pick
>> those up.
>> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx,
>> allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?
> I like this change.
>
> There are some Makefiles under src/mesa/main/.  Are they still used?  Could we
> remove them?

You can remove them.

-Brian

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-4]

2010/2/19 Kristian Høgsberg <krh@...>:

> I applied the patches from Kenneth Graunke on the list for this.  Can
> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
> _mesa_bzero() too?

I've remove _mesa_bzero() just now, plus some other macro wrappers.

We might as well remove the malloc/calloc() wrappers too, but that'll
be a bit more work.


>  What about the _mesa_*printf() functions?  It
> looks to me like they just wrap the platform *printf() functions and
> don't provide any fallbacks if the platform doesn't provide the
> function.

That's probably fine too.


>> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx,
>> allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?
>
> Sounds great.  As George suggests, maybe we can drop dri/fb and
> dri/ffb too?  What about d3d?  I don't know much about the driver, but
> I don't see a lot of commits there since 1999 except mechanical
> changes to keep it compiling.

Those driver can go too as far as I'm concerned.  If there aren't
objections over the next 24 hours or so, feel free to start rm'ing.  I
may be off line this weekend.


> Finally, I'd like to land EGLImage support for the dri2 EGL driver,
> which I should be able to do next week.

Sounds great.

-Brian

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Kristian Høgsberg]

2010/2/19 Brian Paul <brian.e.paul@...>:

> 2010/2/19 Kristian Høgsberg <krh@...>:
>
>> I applied the patches from Kenneth Graunke on the list for this.  Can
>> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
>> _mesa_bzero() too?
>
> I've remove _mesa_bzero() just now, plus some other macro wrappers.
>
> We might as well remove the malloc/calloc() wrappers too, but that'll
> be a bit more work.

I'm using:

  git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g

which does most of the work.  I'll do the same thing for _mesa_calloc
and _mesa_free, review the result and commit that.

>>  What about the _mesa_*printf() functions?  It
>> looks to me like they just wrap the platform *printf() functions and
>> don't provide any fallbacks if the platform doesn't provide the
>> function.
>
> That's probably fine too.

I'll use the same sed line for the *printf functions.

Kristian

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Guillem Jover-2]

Hi!

[ CCing Daniel Borca who used to work on 3dfx support in Mesa and
  libglide, not sure though if he is around or interested anymore. ]

On Thu, 2010-02-18 at 17:25:02 -0700, Brian Paul wrote:
> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx,
> allegro, ggi, dri/mga, dri/mach64.  Maybe more.  Any objections?

Could the drivers for actual hardware (namely glide, tdfx, dri/mga
and dri/mach64) be exempted from removal? I at least still have cards
for those, not sure though how many users might be out there, but
whenever libglide has broken in Debian, I tend to receive bug reports,
so I'd assume there's still some. And it always saddens me a bit when
hardware support gets dropped in projects.

Out of curiousity, are those burdersome to deal with, or hindering
further imrpovements or development in other areas? Anything major
that needs to be done to them? I can perfectly understand the desire
to remove legacy stuff that might block or take much of your time,
keeping them would still be appreciated. I also fear I have my hands
full already with lots of stuff, so cannot offer much of help, at
least right now. Though, I should finally cleanup and commit upstream
some of the libglide patches I have in Debian.

thanks,
guillem

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Kristian Høgsberg]

2010/2/19 Kristian Høgsberg <krh@...>:

> 2010/2/19 Brian Paul <brian.e.paul@...>:
>> 2010/2/19 Kristian Høgsberg <krh@...>:
>>
>>> I applied the patches from Kenneth Graunke on the list for this.  Can
>>> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
>>> _mesa_bzero() too?
>>
>> I've remove _mesa_bzero() just now, plus some other macro wrappers.
>>
>> We might as well remove the malloc/calloc() wrappers too, but that'll
>> be a bit more work.
>
> I'm using:
>
>  git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g
>
> which does most of the work.  I'll do the same thing for _mesa_calloc
> and _mesa_free, review the result and commit that.

All done.  I was looking at the MALLOC, CALLOC, MALLOC_STRUCT,
CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the
_mesa_align_* functions.  Do we want to drop those too?  I hesitated
because src/gallium/README.portability says "Use MALLOC, CALLOC, FREE
instead of the malloc, calloc, free functions."  But as far as I can
see, they're not redefined or anything for gallium and they just
resolve to the standard malloc, calloc and free functions.  Am I
missing something?

Kristian

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Jose Fonseca]

On Fri, 2010-02-19 at 09:42 -0800, Kristian Høgsberg wrote:

> 2010/2/19 Kristian Høgsberg <krh@...>:
> > 2010/2/19 Brian Paul <brian.e.paul@...>:
> >> 2010/2/19 Kristian Høgsberg <krh@...>:
> >>
> >>> I applied the patches from Kenneth Graunke on the list for this.  Can
> >>> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
> >>> _mesa_bzero() too?
> >>
> >> I've remove _mesa_bzero() just now, plus some other macro wrappers.
> >>
> >> We might as well remove the malloc/calloc() wrappers too, but that'll
> >> be a bit more work.
> >
> > I'm using:
> >
> >  git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g
> >
> > which does most of the work.  I'll do the same thing for _mesa_calloc
> > and _mesa_free, review the result and commit that.
>
> All done.  I was looking at the MALLOC, CALLOC, MALLOC_STRUCT,
> CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the
> _mesa_align_* functions.  Do we want to drop those too?  

Given that we'll unify these for gallium and mesa it's better leave them
allone for now -- it will make it easier to search'n'replace when we do
that.

I hope to get started on this task next week.

> I hesitated
> because src/gallium/README.portability says "Use MALLOC, CALLOC, FREE
> instead of the malloc, calloc, free functions."  But as far as I can
> see, they're not redefined or anything for gallium and they just
> resolve to the standard malloc, calloc and free functions.  Am I
> missing something?

On gallium they only resolve to malloc/calloc/free on certain platforms
-- Linux & Windows user space. And even in Windows debug we use malloc
debugging macros.

Jose


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-4]

2010/2/19 Kristian Høgsberg <krh@...>:

> 2010/2/19 Kristian Høgsberg <krh@...>:
>> 2010/2/19 Brian Paul <brian.e.paul@...>:
>>> 2010/2/19 Kristian Høgsberg <krh@...>:
>>>
>>>> I applied the patches from Kenneth Graunke on the list for this.  Can
>>>> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
>>>> _mesa_bzero() too?
>>>
>>> I've remove _mesa_bzero() just now, plus some other macro wrappers.
>>>
>>> We might as well remove the malloc/calloc() wrappers too, but that'll
>>> be a bit more work.
>>
>> I'm using:
>>
>>  git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g
>>
>> which does most of the work.  I'll do the same thing for _mesa_calloc
>> and _mesa_free, review the result and commit that.
>
> All done.  I was looking at the MALLOC, CALLOC, MALLOC_STRUCT,
> CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the
> _mesa_align_* functions.  Do we want to drop those too?  I hesitated
> because src/gallium/README.portability says "Use MALLOC, CALLOC, FREE
> instead of the malloc, calloc, free functions."  But as far as I can
> see, they're not redefined or anything for gallium and they just
> resolve to the standard malloc, calloc and free functions.  Am I
> missing something?

Let's keep the Gallium code as-is.

But for Mesa:

MALLOC_STRUCT and CALLOC_STRUCT should be kept.  They save a lot of typing.

MALLOC, CALLOC, and FREE can go.  The ALIGN macros could probably go
too (just call the align functions).

Years ago, some systems defined malloc() as returning char * instead
of void * so the Mesa wrappers helped with casting.  Plus, back before
valgrind I'd often rig up my own malloc-debug code to track down
memory errors.  The macros were handy for that.

-Brian

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Brian Paul-4]

On Fri, Feb 19, 2010 at 10:59 AM, José Fonseca <jfonseca@...> wrote:

> On Fri, 2010-02-19 at 09:42 -0800, Kristian Høgsberg wrote:
>> 2010/2/19 Kristian Høgsberg <krh@...>:
>> > 2010/2/19 Brian Paul <brian.e.paul@...>:
>> >> 2010/2/19 Kristian Høgsberg <krh@...>:
>> >>
>> >>> I applied the patches from Kenneth Graunke on the list for this.  Can
>> >>> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
>> >>> _mesa_bzero() too?
>> >>
>> >> I've remove _mesa_bzero() just now, plus some other macro wrappers.
>> >>
>> >> We might as well remove the malloc/calloc() wrappers too, but that'll
>> >> be a bit more work.
>> >
>> > I'm using:
>> >
>> >  git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g
>> >
>> > which does most of the work.  I'll do the same thing for _mesa_calloc
>> > and _mesa_free, review the result and commit that.
>>
>> All done.  I was looking at the MALLOC, CALLOC, MALLOC_STRUCT,
>> CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the
>> _mesa_align_* functions.  Do we want to drop those too?
>
> Given that we'll unify these for gallium and mesa it's better leave them
> allone for now -- it will make it easier to search'n'replace when we do
> that.
>
> I hope to get started on this task next week.

OK, disregard my other reply then.  I forgot about this, Jose.

-Brian

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Kristian Høgsberg]

2010/2/19 Brian Paul <brian.e.paul@...>:

> 2010/2/19 Kristian Høgsberg <krh@...>:
>> 2010/2/19 Kristian Høgsberg <krh@...>:
>>> 2010/2/19 Brian Paul <brian.e.paul@...>:
>>>> 2010/2/19 Kristian Høgsberg <krh@...>:
>>>>
>>>>> I applied the patches from Kenneth Graunke on the list for this.  Can
>>>>> we drop  _mesa_malloc(), _mesa_calloc() and _mesa_free() and
>>>>> _mesa_bzero() too?
>>>>
>>>> I've remove _mesa_bzero() just now, plus some other macro wrappers.
>>>>
>>>> We might as well remove the malloc/calloc() wrappers too, but that'll
>>>> be a bit more work.
>>>
>>> I'm using:
>>>
>>>  git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g
>>>
>>> which does most of the work.  I'll do the same thing for _mesa_calloc
>>> and _mesa_free, review the result and commit that.
>>
>> All done.  I was looking at the MALLOC, CALLOC, MALLOC_STRUCT,
>> CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the
>> _mesa_align_* functions.  Do we want to drop those too?  I hesitated
>> because src/gallium/README.portability says "Use MALLOC, CALLOC, FREE
>> instead of the malloc, calloc, free functions."  But as far as I can
>> see, they're not redefined or anything for gallium and they just
>> resolve to the standard malloc, calloc and free functions.  Am I
>> missing something?
>
> Let's keep the Gallium code as-is.
>
> But for Mesa:
>
> MALLOC_STRUCT and CALLOC_STRUCT should be kept.  They save a lot of typing.
>
> MALLOC, CALLOC, and FREE can go.  The ALIGN macros could probably go
> too (just call the align functions).
>
> Years ago, some systems defined malloc() as returning char * instead
> of void * so the Mesa wrappers helped with casting.  Plus, back before
> valgrind I'd often rig up my own malloc-debug code to track down
> memory errors.  The macros were handy for that.

Ok, I droppped the ALIGN macros, but I'll leave the rest as is.  Not
sure what Jose has in mind, but I hope we can drop the MALLOC, CALLOC
and FREE wrappers as well.  At least on Linux today, we have valgrind
and LD_PRELOAD tricks available to do malloc debugging that doesn't
require malloc wrappers.

Kristian

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev