[Mesa-dev] [PATCH 8/9] nir: move to compiler

Jason Ekstrand jason at jlekstrand.net
Tue Dec 15 17:13:13 PST 2015


On Sat, Nov 28, 2015 at 8:45 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 27 November 2015 at 20:45, Jason Ekstrand <jason at jlekstrand.net> wrote:
>> On Nov 27, 2015 11:26 AM, "Matt Turner" <mattst88 at gmail.com> wrote:
>>> On Fri, Nov 27, 2015 at 6:50 AM, Emil Velikov <emil.l.velikov at gmail.com>
>>> wrote:
>>> > On 25 November 2015 at 22:01, Matt Turner <mattst88 at gmail.com> wrote:
>>> >> On Wed, Nov 25, 2015 at 1:32 PM, Emil Velikov
>>> >> <emil.l.velikov at 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)
--Jason


More information about the mesa-dev mailing list