Re: [Mesa3d-dev] Mesa release for the end of March?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Romanick wrote: > Brian Paul wrote: >> 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: > > Part of the reason for the long lead time is to keep my testing group > happy. I don't see a problem moving the branch out a week (to 3/5). > I'll check with them to be sure. I just talked to my QA team leader. Since it doesn't look like any of the proposed changes will impact testing our drivers, he's okay pushing branch creation out a week. I'll plan to make the 7.8 branch on 3/5 instead of 2/26. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuDOWEACgkQX1gOwKyEAw9VGQCgj6CwhfgV2g3IJ0qlEwjbYiw5 DfkAn11TltX3pc0sGtZDeFut6pRDgsrv =oBL7 -END PGP SIGNATURE- -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
On Fri, 2010-02-19 at 14:05 -0800, Corbin Simpson wrote: > On Fri, Feb 19, 2010 at 11:14 AM, Brian Paul wrote: > > Guillem Jover wrote: > >> 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. > > > > I have/had no idea if the tdfx, glide, mga or mach64 drivers function > > anymore. If someone is actively using or testing the drivers I guess > > we could keep them, but I'd rather not otherwise. > > One of my co-workers, bless his soul, is digging out a PCI Voodoo3 for > my collection, so I can maintain tdfx. I don't know about glide. > > I am *not* testing mga; I don't have the right motherboard for it, sorry. mga continues to work surprisingly well, given it's age. I have a few G450 and an G550 here... robert. > mach64's DRM code was getting a once-over by somebody on either > dri-devel or LKML; maybe we could wait and see if somebody cares. > > ~ C. > -- Robert Noland 2Hip Networks -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
On Fri, Feb 19, 2010 at 11:14 AM, Brian Paul wrote: > Guillem Jover wrote: >> 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. > > I have/had no idea if the tdfx, glide, mga or mach64 drivers function > anymore. If someone is actively using or testing the drivers I guess > we could keep them, but I'd rather not otherwise. One of my co-workers, bless his soul, is digging out a PCI Voodoo3 for my collection, so I can maintain tdfx. I don't know about glide. I am *not* testing mga; I don't have the right motherboard for it, sorry. mach64's DRM code was getting a once-over by somebody on either dri-devel or LKML; maybe we could wait and see if somebody cares. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
Guillem Jover wrote: > 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. I have/had no idea if the tdfx, glide, mga or mach64 drivers function anymore. If someone is actively using or testing the drivers I guess we could keep them, but I'd rather not otherwise. > 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. When I change core things in Mesa (like the texformat overhaul last fall) I wonder if the lesser-used drivers still function since I don't test them. In any case, older versions of Mesa with the drivers in question won't go away so people can use those if needed. -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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
On Fri, 2010-02-19 at 10:23 -0800, Kristian Høgsberg wrote: > 2010/2/19 Brian Paul : > > 2010/2/19 Kristian Høgsberg : > >> 2010/2/19 Kristian Høgsberg : > >>> 2010/2/19 Brian Paul : > 2010/2/19 Kristian Høgsberg : > > > 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. My plan was to use pretty much the src/gallium/auxiliary/os/os_memory.h as is. Mesa will never run in kernel mode like gallium needs to, but it still quite cross-platform, so having a thing abstraction on top of STDC free/malloc/calloc is always a convenient. Linux has very nice memory debugging tools indeed, but windows has nothing near valgrind. Even if one is willing to pay. Also the debugging wrappers are convenient because they run every time -- if you introduce a regression you quickly see that in the final report when closing the app. It's not necessary to go out of the way to run a debugging tool. 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul 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: Part of the reason for the long lead time is to keep my testing group happy. I don't see a problem moving the branch out a week (to 3/5). I'll check with them to be sure. > 1. GL_APPLE_object_purgeable - I think the last round of patches > looked OK. Chris? Wow. I thought this was already in. :) > 2. _mesa_memcpy() -> memcpy(), etc. replacement. There were patches > for this that haven't been applied yet. Maybe someone could pick > those up. I think Kenneth Graunke has some patches. > 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'd be in favor of dumping the various unmaintained software rasterization drivers. beos, dos, d3d, and svga could probably be added to that list. I'm not too excited about dumping working hardware drivers, though. We should probably come up with a complete candidate list and circulate it. Any drivers that nobody stands up for should get axed. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt+4KQACgkQX1gOwKyEAw/ZBQCgmkt2WebOUgdjM4tLwP6Qskff UX8An2T7yWjbo79kdsq/CmTD7KhNyib4 =gYtg -END PGP SIGNATURE- -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
2010/2/19 Brian Paul : > 2010/2/19 Kristian Høgsberg : >> 2010/2/19 Kristian Høgsberg : >>> 2010/2/19 Brian Paul : 2010/2/19 Kristian Høgsberg : > 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
On Fri, 2010-02-19 at 09:42 -0800, Kristian Høgsberg wrote: > 2010/2/19 Kristian Høgsberg : > > 2010/2/19 Brian Paul : > >> 2010/2/19 Kristian Høgsberg : > >> > >>> 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
On Fri, Feb 19, 2010 at 10:59 AM, José Fonseca wrote: > On Fri, 2010-02-19 at 09:42 -0800, Kristian Høgsberg wrote: >> 2010/2/19 Kristian Høgsberg : >> > 2010/2/19 Brian Paul : >> >> 2010/2/19 Kristian Høgsberg : >> >> >> >>> 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
2010/2/19 Kristian Høgsberg : > 2010/2/19 Kristian Høgsberg : >> 2010/2/19 Brian Paul : >>> 2010/2/19 Kristian Høgsberg : >>> 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
2010/2/19 Kristian Høgsberg : > 2010/2/19 Brian Paul : >> 2010/2/19 Kristian Høgsberg : >> >>> 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
2010/2/19 Brian Paul : > 2010/2/19 Kristian Høgsberg : > >> 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
2010/2/19 Kristian Høgsberg : > 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
On Thu, Feb 18, 2010 at 9:50 PM, Chia-I Wu wrote: > On Fri, Feb 19, 2010 at 8:25 AM, Brian Paul 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
On Thu, Feb 18, 2010 at 7:25 PM, Brian Paul 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
On Fri, Feb 19, 2010 at 2:25 AM, 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? > - 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
On Fri, Feb 19, 2010 at 8:25 AM, Brian Paul 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? -- o...@lunarg.com -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
tom fogal wrote: > Ian Romanick 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
Ian Romanick 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
-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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
On Thu, Jan 14, 2010 at 2:52 AM, Ian Romanick 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
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" 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-...@lists.sourceforge... -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa release for the end of March?
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Mesa release for the end of March?
-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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
