On Wed, Dec 16, 2015 at 8:53 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 16 December 2015 at 01:13, Jason Ekstrand <ja...@jlekstrand.net> wrote: >> On Sat, Nov 28, 2015 at 8:45 AM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> On 27 November 2015 at 20:45, Jason Ekstrand <ja...@jlekstrand.net> wrote: >>>> On Nov 27, 2015 11:26 AM, "Matt Turner" <matts...@gmail.com> wrote: >>>>> On Fri, Nov 27, 2015 at 6:50 AM, Emil Velikov <emil.l.veli...@gmail.com> >>>>> wrote: >>>>> > On 25 November 2015 at 22:01, Matt Turner <matts...@gmail.com> wrote: >>>>> >> On Wed, Nov 25, 2015 at 1:32 PM, Emil Velikov >>>>> >> <emil.l.veli...@gmail.com> wrote: >>>>> > >>>>> >>> --- a/src/Makefile.am >>>>> >>> +++ b/src/Makefile.am >>>>> >>> @@ -23,6 +23,7 @@ SUBDIRS = . gtest util mapi/glapi/gen mapi >>>>> >>> >>>>> >>> # XXX: conditionally include >>>>> >>> SUBDIRS += compiler >>>>> >>> +SUBDIRS += compiler/nir >>>>> >> >>>>> >> We have a non-recursive build in src/glsl today. I don't want to go >>>>> >> backwards. >>>>> > Not sure I fully get that can you elaborate ? Are you concerned that >>>>> > things won't build in parallel, increasing the compilation times ? >>>>> > >>>>> > On my dual core system running with -j2 results in approx 15 seconds >>>>> > increase. I'm willing to take that trade off for the improved >>>>> > readability. What is the difference on your system ? >>>>> >>>>> src/glsl has single Makefile that builds libglcpp, glcpp, libglsl, >>>>> glsl_compiler, glsl_test, libnir, and various test programs, allowing >>>>> all of these things to happen in parallel. The Makefile is perfectly >>>>> maintainable as it is and there's no advantage of splitting it, >>>>> especially when the work has been done to get things to this state >>>>> (commits 86d30dea, efd201ca) and NIR was added without an additional >>>>> Makefile. >>>> >>>> I would tend to agree. Making things hierarchical is nice but, >>>> unfortunately, autotools makes this and parallelization mutually exclusive. >>> >>> Actually I have some ancient work where we benefit from both. Namely >>> have a single top level Makefile.am, which directly includes the >>> subdirectory Automake.mk files, resulting in one big Makefile at the >>> very end. >>> >>> That aside can we get some quantitative representation of the penalty >>> you guys see. On my (old) machine the difference is negligible ~15 >>> sec of a ~11 minute `make all' and ~16 minute `make distcheck'. >> >> What happened to this? (Yes, "Busy doing a release" is a valid answer) > > There is a question in there for which I was waiting for an answer. > Here it is again - split from the rest, with a question mark (silly > me). > > Can anyone confirm how much of a penalty are we talking about (single > vs separate makefiles) ?
I'm not going to take the time to quantify it. Just do a clean build and watch as 7 of your 8 cores sit idle as format_srgb.c is generated or shared-glapi/libglapi.la is linked. (A dual-core system is not going to demonstrate this issue properly) The point is that *I've already done the work* to prevent these kinds of things from happening in src/glsl and I am *not* interested in going back on that, especially for no reason at all. Just tell me if you don't want to do this project (moving things to src/compiler) and I'll take over. > Getting these makefiles benefit from parallelism, whist retaining the > split, is reasonably straight forward*. Unless there's something I've misunderstood or don't know... No, no it's not. > > Thanks > Emil > > * Once we find out how to "hack" scons. Will contact Jose and others > on the topic shortly. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
