Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Fri, Aug 13, 2010 at 4:58 PM, Aras Pranckevicius a...@unity3d.com wrote: But I perceive talloc as different from all above: it's very low level and low weight library, providing very basic functionality, and upstream never showed interest for Windows portability. I'd really prefer to see the talloc source bundled (and only compiled on windows), as a quick way to have glsl2 merged without causing windows build failures. This seems like a reasonable compromise. Is this something that you and / or Aras can tackle? I don't have a Windows build system set up, so I wouldn't be able to test any build system changes that I made. Ok, looks like how/if to bundle talloc is still a very open question. In the meantime, here's talloc 2.0.1 made to compile (and possibly work!) with Visual C++ 2008 (Windows) and Xcode/gcc4.0 (Mac). I've attached the modified talloc.c talloc.h and the patch from original talloc 2.0.1 (from here http://samba.org/ftp/talloc/). Caveat emptor: I only verified this to work on my own GLSL2 fork, which does not compile in GLSL2 preprocessor, only the compiler optimizer. Like I said before, full port of talloc seems to be not needed for compiling on Visual C++; just drop in talloc.h talloc.c into the project and that's it. Same for Mac with Xcode. It also seems that GLSL2 does not use full talloc's functionality, and at least half of the implementation could be dropped without anyone noticing. Just a note for if/when anyone would try to re-implement talloc with Mesa's license. Be careful about LGPLv3 rules, If you are distributing anything linked with an LGPL library without accompanying source you need to dynamically link it, So for example a Windows driver or non open compiler, you can't just drop the LGPLv3 c+h files into the project, you need to create a dynamic library. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
Like I said before, full port of talloc seems to be not needed for compiling on Visual C++; just drop in talloc.h talloc.c into the project and that's it. Same for Mac with Xcode. Be careful about LGPLv3 rules, If you are distributing anything linked with an LGPL library without accompanying source you need to dynamically link it I know. I'm just providing a MSVC/Xcode compatible talloc source file. How Mesa or some fork of Mesa includes it in the build or packages it up - I'll just leave that up to them. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Thu, 2010-08-12 at 14:46 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 José Fonseca wrote: OK. What about this: For GLUT, GLEW, LLVM and all other dependencies I'll just make a SDK with the binaries, with debug release, 32 64 bit, MinGW MSVC versions. One seldom needs to modify the source anyway, and they have active upstream development. But I perceive talloc as different from all above: it's very low level and low weight library, providing very basic functionality, and upstream never showed interest for Windows portability. I'd really prefer to see the talloc source bundled (and only compiled on windows), as a quick way to have glsl2 merged without causing windows build failures. This seems like a reasonable compromise. Is this something that you and / or Aras can tackle? I don't have a Windows build system set up, so I wouldn't be able to test any build system changes that I made. I've pushed a new branch glsl2-win32 that includes Aras' patch, and all necessary fixes to get at least MinGW build successfully. I had to rename some tokens in order to avoid collisions with windows.h defines. Aras didn't mention this problem before. Perhaps the indirect windows.h include can be avoided, or you prefer to handle this some other way. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
I had to rename some tokens in order to avoid collisions with windows.h defines. Aras didn't mention this problem before. I mentioned this to Eric in private conversation, but on this list I only talked about talloc specific changes. Yeah, in the glsl2 parser some tokens clash with windows headers (BOOL, INPUT etc.), and windows.h is indirectly included by Mesa's own gl.h. I've been doing renames of them in my own fork. Maybe bulk of glsl2 does not need to include that much of Mesa itself (e.g. right now you need to have things like src/mapi/mapi/u_thread.h and src/mesa/math/m_matrix.h - because they are included indirectly by something that glsl2 includes). -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Wed, 2010-08-11 at 17:40 -0700, Dave Airlie wrote: On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca jfons...@vmware.com wrote: On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 José Fonseca wrote: Could then Aras Pranckevicius's talloc port to windows be merged into glsl2 branch before glsl2 is merged into master? I think we learned our lesson with GLEW. Trying to keep a copy of an external dependency in our tree only leads to sadness. I have no intention to repeat that mistake. Having the GLEW source was quite useful for windows. I guess the lesson would not be not ship source, but only build it if necessary. If talloc source is not needed for Linux then we can just build it when absent. You can even ignore it from automake. Can't you guys setup a separate windows deps repo? that you gather all the prereqs for building on Windows in one place and recommend people check it out before mesa? Unfortunately there is no standard way to install headers and libraries in windows -- there's no /usr/include or /usr/lib, and there might be multiple MSVC versions. There are ways around it, sure. Might be worth giving a shot eventually. Really optimising for the wrong bunch of people here by dragging this stuff into mesa git. Many projects do this: they include the source of other projects, to make it easier to build without having to build all dependencies. If this is still bothersome, I can make sure it's only built on non-unix platforms. We can even put in src/thirdparty/... or somewhere else out of the way. I really can't see how this causes inconvenience to anybody. Furthermore, I really don't know any wrong bunch of people here. But I do know at least one prejudiced person with delusions of grandeur. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Thu, Aug 12, 2010 at 9:00 PM, José Fonseca jfons...@vmware.com wrote: On Wed, 2010-08-11 at 17:40 -0700, Dave Airlie wrote: On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca jfons...@vmware.com wrote: On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 José Fonseca wrote: Could then Aras Pranckevicius's talloc port to windows be merged into glsl2 branch before glsl2 is merged into master? I think we learned our lesson with GLEW. Trying to keep a copy of an external dependency in our tree only leads to sadness. I have no intention to repeat that mistake. Having the GLEW source was quite useful for windows. I guess the lesson would not be not ship source, but only build it if necessary. If talloc source is not needed for Linux then we can just build it when absent. You can even ignore it from automake. Can't you guys setup a separate windows deps repo? that you gather all the prereqs for building on Windows in one place and recommend people check it out before mesa? Unfortunately there is no standard way to install headers and libraries in windows -- there's no /usr/include or /usr/lib, and there might be multiple MSVC versions. There are ways around it, sure. Might be worth giving a shot eventually. Really optimising for the wrong bunch of people here by dragging this stuff into mesa git. Many projects do this: they include the source of other projects, to make it easier to build without having to build all dependencies. We spend a lot of time unbundling stuff in projects because its a really bad model, esp for things like security updates. What happens if the version of talloc we ship ends up a with a problem and nobody is tracking upstream and notices the issue, this doesn't scale, at some point you have to draw a line, again you have 0 experience with packaging mesa for its main purpose and use case, so excuse me if I dismiss the rest of your pithy comments. talloc is a bit different than glew I can accept that, since glew isn't a mesa build req, but should we start shipping bison, flex etc, is it only build reqs or runtime reqs? it would be nice instead of being an ass you perhaps helped draw up some guidelines with all the other Windows folks. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Thu, 2010-08-12 at 04:10 -0700, Dave Airlie wrote: On Thu, Aug 12, 2010 at 9:00 PM, José Fonseca jfons...@vmware.com wrote: On Wed, 2010-08-11 at 17:40 -0700, Dave Airlie wrote: On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca jfons...@vmware.com wrote: On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 José Fonseca wrote: Could then Aras Pranckevicius's talloc port to windows be merged into glsl2 branch before glsl2 is merged into master? I think we learned our lesson with GLEW. Trying to keep a copy of an external dependency in our tree only leads to sadness. I have no intention to repeat that mistake. Having the GLEW source was quite useful for windows. I guess the lesson would not be not ship source, but only build it if necessary. If talloc source is not needed for Linux then we can just build it when absent. You can even ignore it from automake. Can't you guys setup a separate windows deps repo? that you gather all the prereqs for building on Windows in one place and recommend people check it out before mesa? Unfortunately there is no standard way to install headers and libraries in windows -- there's no /usr/include or /usr/lib, and there might be multiple MSVC versions. There are ways around it, sure. Might be worth giving a shot eventually. Really optimising for the wrong bunch of people here by dragging this stuff into mesa git. Many projects do this: they include the source of other projects, to make it easier to build without having to build all dependencies. We spend a lot of time unbundling stuff in projects because its a really bad model, esp for things like security updates. What happens if the version of talloc we ship ends up a with a problem and nobody is tracking upstream and notices the issue, this doesn't scale, at some point you have to draw a line, again you have 0 experience with packaging mesa for its main purpose and use case, so excuse me if I dismiss the rest of your pithy comments. Good points, but I still don't see how my proposal of not building them on linux does not address them. talloc is a bit different than glew I can accept that, since glew isn't a mesa build req, but should we start shipping bison, flex etc, is it only build reqs or runtime reqs? no. but that's why we commit the bison and flex output in the repository for example. it would be nice instead of being an ass you perhaps helped draw up some guidelines with all the other Windows folks. my feelings exactly when I read the last sentence of your previous email. in a hindsight perhaps you meant distributions + end users vs developers, but I understood it as windows developers == bunch of wrong people, and linux developers == bunch of good people. who cares. there isn't wrong bunch of people regardless. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca jfons...@vmware.com wrote: Really optimising for the wrong bunch of people here by dragging this stuff into mesa git. Many projects do this: they include the source of other projects, to make it easier to build without having to build all dependencies. This is true, but it's also quite annoying. Take ioquake3 for example, in order to make it simpler for Windows and Mac OS developers, they include in SVN things like the libSDL headers, OpenAL headers, static libraries for OpenAL, libSDL, and libcurl, and the sources for libspeex, libcurl, and zlib. So the Linux packagers have to jump through hoops trying to untangle this mess. What Dave's saying with optimizing for the wrong people is that we're including lots of things in the Mesa code that most people (most users of Mesa are Linux/BSD/UNIX users) don't need, and by including these things with Mesa, we're making it more difficult to package Mesa for most people. Frankly, it's also a bit hard to empathize with any this makes Windows development harder arguments when we don't have the code that you're building on Windows. But I digress... Surely moving external build dependencies to another git repository would satisfy everyone. On another note, Dave might sound annoyed in these emails, but if he's like me, it's because he's read lots of emails about problems caused by Windows that, again, most people don't care about, and has held back on saying anything until now. It is frustrating to see things like merging glsl2 held up because of Windows. Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Thu, 2010-08-12 at 07:58 -0700, Matt Turner wrote: On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca jfons...@vmware.com wrote: Really optimising for the wrong bunch of people here by dragging this stuff into mesa git. Many projects do this: they include the source of other projects, to make it easier to build without having to build all dependencies. This is true, but it's also quite annoying. Take ioquake3 for example, in order to make it simpler for Windows and Mac OS developers, they include in SVN things like the libSDL headers, OpenAL headers, static libraries for OpenAL, libSDL, and libcurl, and the sources for libspeex, libcurl, and zlib. So the Linux packagers have to jump through hoops trying to untangle this mess. What Dave's saying with optimizing for the wrong people is that we're including lots of things in the Mesa code that most people (most users of Mesa are Linux/BSD/UNIX users) don't need, and by including these things with Mesa, we're making it more difficult to package Mesa for most people. Frankly, it's also a bit hard to empathize with any this makes Windows development harder arguments when we don't have the code that you're building on Windows. But I digress... How come? All code to build on softpipe/llvmpipe on windows is checked into mesa (at least until talloc dependency is added). Read http://www.mesa3d.org/install.html#scons for softpipe instructions, and http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/llvmpipe/README for llvmpipe. It gives you a software implementation of OpenGL way better than the one that comes bundled with Windows. Surely moving external build dependencies to another git repository would satisfy everyone. On another note, Dave might sound annoyed in these emails, but if he's like me, it's because he's read lots of emails about problems caused by Windows that, again, most people don't care about, and has held back on saying anything until now. It is frustrating to see things like merging glsl2 held up because of Windows. That's short sighted. Windows has a lot of weight economically, and Gallium is only where it is today because it tapped into that. So you focus on the negative aspects of supporting Windows, but you ignore all the goodness that came from (in particular all the QA and bugfixing done with windows apps, that are far more complex than most stuff available for linux, in particular games CAD apps). Anyway, if you turn this into a Windows vs Linux battle I'm bound to loose here. Especially because I don't even use it personally -- for me it's no different than another embedded platform for which I write drivers and debug remotely from my Linux development machine. It's just that I don't like to shit where I eat. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Thu, Aug 12, 2010 at 11:27 AM, José Fonseca jfons...@vmware.com wrote: On Thu, 2010-08-12 at 07:58 -0700, Matt Turner wrote: On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca jfons...@vmware.com wrote: Really optimising for the wrong bunch of people here by dragging this stuff into mesa git. Many projects do this: they include the source of other projects, to make it easier to build without having to build all dependencies. This is true, but it's also quite annoying. Take ioquake3 for example, in order to make it simpler for Windows and Mac OS developers, they include in SVN things like the libSDL headers, OpenAL headers, static libraries for OpenAL, libSDL, and libcurl, and the sources for libspeex, libcurl, and zlib. So the Linux packagers have to jump through hoops trying to untangle this mess. What Dave's saying with optimizing for the wrong people is that we're including lots of things in the Mesa code that most people (most users of Mesa are Linux/BSD/UNIX users) don't need, and by including these things with Mesa, we're making it more difficult to package Mesa for most people. Frankly, it's also a bit hard to empathize with any this makes Windows development harder arguments when we don't have the code that you're building on Windows. But I digress... How come? All code to build on softpipe/llvmpipe on windows is checked into mesa (at least until talloc dependency is added). Read http://www.mesa3d.org/install.html#scons for softpipe instructions, and http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/llvmpipe/README for llvmpipe. It gives you a software implementation of OpenGL way better than the one that comes bundled with Windows. OK, that's fair enough. Surely moving external build dependencies to another git repository would satisfy everyone. On another note, Dave might sound annoyed in these emails, but if he's like me, it's because he's read lots of emails about problems caused by Windows that, again, most people don't care about, and has held back on saying anything until now. It is frustrating to see things like merging glsl2 held up because of Windows. That's short sighted. Windows has a lot of weight economically, and Gallium is only where it is today because it tapped into that. So you focus on the negative aspects of supporting Windows, but you ignore all the goodness that came from (in particular all the QA and bugfixing done with windows apps, that are far more complex than most stuff available for linux, in particular games CAD apps). Cool, I'm glad to hear that it helps with QA. Anyway, if you turn this into a Windows vs Linux battle I'm bound to loose here. Especially because I don't even use it personally -- for me it's no different than another embedded platform for which I write drivers and debug remotely from my Linux development machine. It's just that I don't like to shit where I eat. Jose That's not really my intention. I think we can easily end the whole discussion just by moving the build dependencies that are used for Windows to a separate repository. It shouldn't make things more difficult for the VMware guys (I wouldn't think, at least) and it would make things cleaner for the Linux guys. Thanks for the response, José. :) Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Thu, 2010-08-12 at 08:33 -0700, Matt Turner wrote: On Thu, Aug 12, 2010 at 11:27 AM, José Fonseca jfons...@vmware.com wrote: On Thu, 2010-08-12 at 07:58 -0700, Matt Turner wrote: On Thu, Aug 12, 2010 at 7:00 AM, José Fonseca jfons...@vmware.com wrote: Really optimising for the wrong bunch of people here by dragging this stuff into mesa git. Many projects do this: they include the source of other projects, to make it easier to build without having to build all dependencies. This is true, but it's also quite annoying. Take ioquake3 for example, in order to make it simpler for Windows and Mac OS developers, they include in SVN things like the libSDL headers, OpenAL headers, static libraries for OpenAL, libSDL, and libcurl, and the sources for libspeex, libcurl, and zlib. So the Linux packagers have to jump through hoops trying to untangle this mess. What Dave's saying with optimizing for the wrong people is that we're including lots of things in the Mesa code that most people (most users of Mesa are Linux/BSD/UNIX users) don't need, and by including these things with Mesa, we're making it more difficult to package Mesa for most people. [...] That's not really my intention. I think we can easily end the whole discussion just by moving the build dependencies that are used for Windows to a separate repository. It shouldn't make things more difficult for the VMware guys (I wouldn't think, at least) and it would make things cleaner for the Linux guys. OK. What about this: For GLUT, GLEW, LLVM and all other dependencies I'll just make a SDK with the binaries, with debug release, 32 64 bit, MinGW MSVC versions. One seldom needs to modify the source anyway, and they have active upstream development. But I perceive talloc as different from all above: it's very low level and low weight library, providing very basic functionality, and upstream never showed interest for Windows portability. I'd really prefer to see the talloc source bundled (and only compiled on windows), as a quick way to have glsl2 merged without causing windows build failures. (Hopefully in the future we could have jakob Bornecrantz or Aras Pranckevičius re-implement a BSD-like version of it, and therefore eliminating all the different licensing concerns.) Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Tue, 2010-08-10 at 22:57 -0700, Aras Pranckevicius wrote: No, it's missing most of the API that talloc provides. Also, http://github.com/aras-p/glsl-optimizer/ ported it to windows. Could then Aras Pranckevicius's talloc port to windows be merged into glsl2 branch before glsl2 is merged into master? First things first: I needed to make it compile work quickly, so I just dropped talloc.h and talloc.c into my project (http://github.com/aras-p/glsl-optimizer/tree/glsl2/src/glsl/msvc/talloc/) and made some fixes. So I wouldn't call it a full port, but apparently it was enough without taking everything that is in official talloc tarball. However, I'm not really sure if that is legal license wise (talloc is LGPLv3). I'm not a lawyer, but my understanding is that if you copy the license files too, then it should be alright. I'd personally prefer src/talloc instead of src/glsl/msvc/talloc/ . That said, the only fixes I had to do are Visual C++ specific (I'm using VS2008): * compile talloc.c as C++ (otherwise 'inline' etc. are errors on MSVC). This required wrapping talloc.h and talloc.c in extern C blocks: http://github.com/aras-p/glsl-optimizer/commit/ceee99ebe0c606de6ed093c2aec20f8ecae5b673 Using C++ is overkill. The solution is simply to use the MSVC inline keyword (__inline, or something, see p_compiler.h). * vsnprintf can't be used to determine output buffer size; under MSVC _vcsprintf has to be used instead. http://github.com/aras-p/glsl-optimizer/commit/56bb0c7e7cedefcd2d149011a0b644551e080b9a * Replaced usage of MIN to TALLOC_MIN, and defined TALLOC_MIN: http://github.com/aras-p/glsl-optimizer/commit/db96499fbf874582b81dabedebc835c950520211 (there's accidental line of unrelated change in that commit) Compiling on Mac with Xcode 3.2 (using gcc 4.0) required MIN-TALLOC_MIN change and compiling as C++ with extern C blocks as well. Could you please prepare a patch? Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 José Fonseca wrote: Could then Aras Pranckevicius's talloc port to windows be merged into glsl2 branch before glsl2 is merged into master? I think we learned our lesson with GLEW. Trying to keep a copy of an external dependency in our tree only leads to sadness. I have no intention to repeat that mistake. I suspect there may also be some issue with including a piece of software with such a different license in our tree. I'm not a lawyer, so I may be unnecessarily paranoid here. *shrug* -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxi/3gACgkQX1gOwKyEAw/lrgCZAeyrTvpPq8mJthi4+HC2r8bo qywAn1hk9uVsAg7DyaYVh0oYJLfOMOAP =VVky -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
Could then Aras Pranckevicius's talloc port to windows be merged into glsl2 branch before glsl2 is merged into master? I think we learned our lesson with GLEW. Trying to keep a copy of an external dependency in our tree only leads to sadness. I have no intention to repeat that mistake. I suspect there may also be some issue with including a piece of software with such a different license in our tree. I'm not a lawyer, so I may be unnecessarily paranoid here. *shrug* Another option I was considering (mostly for my own needs; I need to use GLSL2 fork in a closed source product) is a from-scratch implementation of talloc that keeps the same interface. Similar to what Mono folks have did with glib (they wrote their own eglib that matched the license and was much smaller in the result). In my case, talloc's LGPL is quite a hassle because I have to build talloc dlls/dylibs, which complicates deployment packaging, etc. I had not time to do that yet and probably won't have in the next month or two though :( talloc is not very large, looks like just taking one .h and .c file is enough. And then there are quite a few functions that GLSL2 does not ever use. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 José Fonseca wrote: Could then Aras Pranckevicius's talloc port to windows be merged into glsl2 branch before glsl2 is merged into master? I think we learned our lesson with GLEW. Trying to keep a copy of an external dependency in our tree only leads to sadness. I have no intention to repeat that mistake. Having the GLEW source was quite useful for windows. I guess the lesson would not be not ship source, but only build it if necessary. If talloc source is not needed for Linux then we can just build it when absent. You can even ignore it from automake. I suspect there may also be some issue with including a piece of software with such a different license in our tree. I'm not a lawyer, so I may be unnecessarily paranoid here. *shrug* I'm not a lawyer neither but this is paranoid IMHO. How the source of multiple open source works is layed out or packaged is seldom prescribed in open source licenses. It's all about how multiple works are linked into binary form and distributed. LGPLv3 is quite clear here on this matter too, per http://www.gnu.org/licenses/lgpl.html , point 4 Combined Works, and point 5, Combined Libraries. If indeed, LGPLv3 puts us in muddy waters then the talloc dependency should never be added. Keeping its source out of mesa alters nothing. So let's be consistent here. FWIW, the talloc dependency is not worth its salt. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Wed, 2010-08-11 at 13:18 -0700, Aras Pranckevicius wrote: Could then Aras Pranckevicius's talloc port to windows be merged into glsl2 branch before glsl2 is merged into master? I think we learned our lesson with GLEW. Trying to keep a copy of an external dependency in our tree only leads to sadness. I have no intention to repeat that mistake. I suspect there may also be some issue with including a piece of software with such a different license in our tree. I'm not a lawyer, so I may be unnecessarily paranoid here. *shrug* Another option I was considering (mostly for my own needs; I need to use GLSL2 fork in a closed source product) is a from-scratch implementation of talloc that keeps the same interface. Similar to what Mono folks have did with glib (they wrote their own eglib that matched the license and was much smaller in the result). That's a good idea. Jakob was also considering adding the missing bits to http://swapped.cc/halloc/ to make it compatible with talloc at source level. In my case, talloc's LGPL is quite a hassle because I have to build talloc dlls/dylibs, which complicates deployment packaging, etc. I had not time to do that yet and probably won't have in the next month or two though :( talloc is not very large, looks like just taking one .h and .c file is enough. And then there are quite a few functions that GLSL2 does not ever use. I really can't condone the glsl2 branch merge until we have some consensus on how the talloc dependency should be handled, windows or not. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Thu, Aug 12, 2010 at 9:42 AM, José Fonseca jfons...@vmware.com wrote: On Wed, 2010-08-11 at 12:52 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 José Fonseca wrote: Could then Aras Pranckevicius's talloc port to windows be merged into glsl2 branch before glsl2 is merged into master? I think we learned our lesson with GLEW. Trying to keep a copy of an external dependency in our tree only leads to sadness. I have no intention to repeat that mistake. Having the GLEW source was quite useful for windows. I guess the lesson would not be not ship source, but only build it if necessary. If talloc source is not needed for Linux then we can just build it when absent. You can even ignore it from automake. Can't you guys setup a separate windows deps repo? that you gather all the prereqs for building on Windows in one place and recommend people check it out before mesa? Really optimising for the wrong bunch of people here by dragging this stuff into mesa git. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Sun, 2010-08-01 at 10:19 -0700, Eric Anholt wrote: On Tue, 27 Jul 2010 21:32:57 +0100, José Fonseca jfons...@vmware.com wrote: On Wed, 2010-07-21 at 18:53 -0700, Ian Romanick wrote: As everyone knows, a group of us at Intel have been rewriting Mesa's GLSL compiler. The work started out-of-tree as a stand alone compiler. We moved all of our work to the glsl2 branch in the Mesa tree as soon as we had some actual code being generated. This was about month ago. Since that time we have implemented quite a bit more code generation and a complete linker. The compiler is not done, but it gets closer every day. I think now is the time to start discussing merge criteria. It is well known that the Intel graphics team favors quarterly releases. In order to align with other people's release schedules, we'd really like to have the new compiler in a Mesa release at the end of Q3 (end of September / beginning of October). That's just over two months from now. In order to have a credible release, the compiler needs to be merged to master before then. A reasonable estimate puts the end of August as the latest possible merge time. Given how far the compiler has come in the last month, I have a lot of faith in being able to hit that target. We have developed our own set of merge requirements, and these are listed below. Since this is such a large subsystem, we want to solicit input from the other stakeholders. * No piglit regressions, except draw_buffers-05.vert, compared to master in swrast, i965, or i915. * Any failing tests do not crash (segfault, assertion failure, etc.). draw_buffers-05.vert is specifically excluded because I'm not sure the test is correct. One of the items on the TODO list is proper support for GLSL ES. That work won't happen until the last couple weeks of August, so I don't think any sort of ES testing is suitable merge criteria. Unless, of course, the tests in question should also work on desktop GLSL. We haven't and, for all practical purposes, can't test with Gallium or other hardware drivers. The new compiler generates the same assembly IR that the current compiler generates. We haven't added any instructions. It does, however, generate different combinations of instructions, different uses of registers, and so on. We don't expect there to be significant impact on other hardware, but there may be some. The optimizer in r300 will certainly see different sequences of instructions than it is accustomed to seeing. I can't foresee what impact this will have on that driver. I have put up the results of master and the glsl2 branch at http://people.freedesktop.org/~idr/results/. This run off compiler.tests from the glsl2 branch of Eric's piglit repository. A few of the failures (half a dozen or so) on master seem to be mutex related in the GLX code. Kristian is working on fixing that. :) We're already very close to our proposed merge criteria. I was recently made aware that glsl2 adds an hard dependency on the talloc library. Is this correct? I doesn't seem that talloc has ever been ported to Windows or MSVC, although it seems small. There's also the fact that it's a dependency with a very different license from Mesa (LGPLv3). This is not an obstacle on itself, but it makes it harder to simply bundle the code into mesa and port it ourselves. At a first glance it seems that talloc gives a tad more trouble than what it's worth. Did you guys investigate other alternatives? talloc.c mentions it was inspired by http://swapped.cc/halloc/ , which is BSD license and seems trivial to port to MSVC. Would that also fit your needs? No, it's missing most of the API that talloc provides. Also, http://github.com/aras-p/glsl-optimizer/ ported it to windows. Could then Aras Pranckevicius's talloc port to windows be merged into glsl2 branch before glsl2 is merged into master? Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
No, it's missing most of the API that talloc provides. Also, http://github.com/aras-p/glsl-optimizer/ ported it to windows. Could then Aras Pranckevicius's talloc port to windows be merged into glsl2 branch before glsl2 is merged into master? First things first: I needed to make it compile work quickly, so I just dropped talloc.h and talloc.c into my project ( http://github.com/aras-p/glsl-optimizer/tree/glsl2/src/glsl/msvc/talloc/) and made some fixes. So I wouldn't call it a full port, but apparently it was enough without taking everything that is in official talloc tarball. However, I'm not really sure if that is legal license wise (talloc is LGPLv3). That said, the only fixes I had to do are Visual C++ specific (I'm using VS2008): - compile talloc.c as C++ (otherwise 'inline' etc. are errors on MSVC). This required wrapping talloc.h and talloc.c in extern C blocks: http://github.com/aras-p/glsl-optimizer/commit/ceee99ebe0c606de6ed093c2aec20f8ecae5b673 - vsnprintf can't be used to determine output buffer size; under MSVC _vcsprintf has to be used instead. http://github.com/aras-p/glsl-optimizer/commit/56bb0c7e7cedefcd2d149011a0b644551e080b9a - Replaced usage of MIN to TALLOC_MIN, and defined TALLOC_MIN: http://github.com/aras-p/glsl-optimizer/commit/db96499fbf874582b81dabedebc835c950520211(there's accidental line of unrelated change in that commit) Compiling on Mac with Xcode 3.2 (using gcc 4.0) required MIN-TALLOC_MIN change and compiling as C++ with extern C blocks as well. -- Aras Pranckevičius work: http://unity3d.com home: http://aras-p.info ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Tue, 27 Jul 2010 21:32:57 +0100, José Fonseca jfons...@vmware.com wrote: On Wed, 2010-07-21 at 18:53 -0700, Ian Romanick wrote: As everyone knows, a group of us at Intel have been rewriting Mesa's GLSL compiler. The work started out-of-tree as a stand alone compiler. We moved all of our work to the glsl2 branch in the Mesa tree as soon as we had some actual code being generated. This was about month ago. Since that time we have implemented quite a bit more code generation and a complete linker. The compiler is not done, but it gets closer every day. I think now is the time to start discussing merge criteria. It is well known that the Intel graphics team favors quarterly releases. In order to align with other people's release schedules, we'd really like to have the new compiler in a Mesa release at the end of Q3 (end of September / beginning of October). That's just over two months from now. In order to have a credible release, the compiler needs to be merged to master before then. A reasonable estimate puts the end of August as the latest possible merge time. Given how far the compiler has come in the last month, I have a lot of faith in being able to hit that target. We have developed our own set of merge requirements, and these are listed below. Since this is such a large subsystem, we want to solicit input from the other stakeholders. * No piglit regressions, except draw_buffers-05.vert, compared to master in swrast, i965, or i915. * Any failing tests do not crash (segfault, assertion failure, etc.). draw_buffers-05.vert is specifically excluded because I'm not sure the test is correct. One of the items on the TODO list is proper support for GLSL ES. That work won't happen until the last couple weeks of August, so I don't think any sort of ES testing is suitable merge criteria. Unless, of course, the tests in question should also work on desktop GLSL. We haven't and, for all practical purposes, can't test with Gallium or other hardware drivers. The new compiler generates the same assembly IR that the current compiler generates. We haven't added any instructions. It does, however, generate different combinations of instructions, different uses of registers, and so on. We don't expect there to be significant impact on other hardware, but there may be some. The optimizer in r300 will certainly see different sequences of instructions than it is accustomed to seeing. I can't foresee what impact this will have on that driver. I have put up the results of master and the glsl2 branch at http://people.freedesktop.org/~idr/results/. This run off compiler.tests from the glsl2 branch of Eric's piglit repository. A few of the failures (half a dozen or so) on master seem to be mutex related in the GLX code. Kristian is working on fixing that. :) We're already very close to our proposed merge criteria. I was recently made aware that glsl2 adds an hard dependency on the talloc library. Is this correct? I doesn't seem that talloc has ever been ported to Windows or MSVC, although it seems small. There's also the fact that it's a dependency with a very different license from Mesa (LGPLv3). This is not an obstacle on itself, but it makes it harder to simply bundle the code into mesa and port it ourselves. At a first glance it seems that talloc gives a tad more trouble than what it's worth. Did you guys investigate other alternatives? talloc.c mentions it was inspired by http://swapped.cc/halloc/ , which is BSD license and seems trivial to port to MSVC. Would that also fit your needs? No, it's missing most of the API that talloc provides. Also, http://github.com/aras-p/glsl-optimizer/ ported it to windows. pgpzMs2WHUjxw.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
On Wed, 2010-07-21 at 18:53 -0700, Ian Romanick wrote: As everyone knows, a group of us at Intel have been rewriting Mesa's GLSL compiler. The work started out-of-tree as a stand alone compiler. We moved all of our work to the glsl2 branch in the Mesa tree as soon as we had some actual code being generated. This was about month ago. Since that time we have implemented quite a bit more code generation and a complete linker. The compiler is not done, but it gets closer every day. I think now is the time to start discussing merge criteria. It is well known that the Intel graphics team favors quarterly releases. In order to align with other people's release schedules, we'd really like to have the new compiler in a Mesa release at the end of Q3 (end of September / beginning of October). That's just over two months from now. In order to have a credible release, the compiler needs to be merged to master before then. A reasonable estimate puts the end of August as the latest possible merge time. Given how far the compiler has come in the last month, I have a lot of faith in being able to hit that target. We have developed our own set of merge requirements, and these are listed below. Since this is such a large subsystem, we want to solicit input from the other stakeholders. * No piglit regressions, except draw_buffers-05.vert, compared to master in swrast, i965, or i915. * Any failing tests do not crash (segfault, assertion failure, etc.). draw_buffers-05.vert is specifically excluded because I'm not sure the test is correct. One of the items on the TODO list is proper support for GLSL ES. That work won't happen until the last couple weeks of August, so I don't think any sort of ES testing is suitable merge criteria. Unless, of course, the tests in question should also work on desktop GLSL. We haven't and, for all practical purposes, can't test with Gallium or other hardware drivers. The new compiler generates the same assembly IR that the current compiler generates. We haven't added any instructions. It does, however, generate different combinations of instructions, different uses of registers, and so on. We don't expect there to be significant impact on other hardware, but there may be some. The optimizer in r300 will certainly see different sequences of instructions than it is accustomed to seeing. I can't foresee what impact this will have on that driver. I have put up the results of master and the glsl2 branch at http://people.freedesktop.org/~idr/results/. This run off compiler.tests from the glsl2 branch of Eric's piglit repository. A few of the failures (half a dozen or so) on master seem to be mutex related in the GLX code. Kristian is working on fixing that. :) We're already very close to our proposed merge criteria. I was recently made aware that glsl2 adds an hard dependency on the talloc library. Is this correct? I doesn't seem that talloc has ever been ported to Windows or MSVC, although it seems small. There's also the fact that it's a dependency with a very different license from Mesa (LGPLv3). This is not an obstacle on itself, but it makes it harder to simply bundle the code into mesa and port it ourselves. At a first glance it seems that talloc gives a tad more trouble than what it's worth. Did you guys investigate other alternatives? talloc.c mentions it was inspired by http://swapped.cc/halloc/ , which is BSD license and seems trivial to port to MSVC. Would that also fit your needs? Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
