On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand <jason@xxxxxxxxxxxxxx> wrote:
On March 16, 2017 5:41:24 PM Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote:
On 17 March 2017 at 00:21, Dylan Baker <dylan@xxxxxxxxxxxxx> wrote:
Hi Emil,You are still failing to see past your usecase. As said before - if
Quoting Emil Velikov (2017-03-16 16:35:33)
While I can see you're impressed by Meson, I would kindly urge you to
not use it here. As you look closely you can see that one could
trivially improve the times, yet the biggest thing is that most of the
code in libdrm must go ;-)
Perhaps I wasn't clear enough, I don't really expect this to land ever. I sent
it out more because I'd written it and it works and is a useful demonstration of
meson+ninja performance. Obviously 20 seconds -> 5 seconds isn't a huge deal :);
but in a larger project, consider that a 4x speedup would be 4 minutes to 1
minute, and that is a huge difference in time.
there's any need to improve things say so.
Note that you simply cannot apply the 1000x speedup in any situation.
Yes, you can't just linearly apply any scaling factor. However, when you build mesa on a machine with a decent number of threads (I think our build machine for the CI system has 32 threads), autotools+make is slow as mud. Also, there's very little you can do to speed up configure since it's a pile of shell and perl that inherently runs single-threaded and is fairly complex due to mesa's complicated dependencies.
You already (explicitly) mentioned some differences. Admittedly not aAs the port is not 1:1 wrt the autoconf one, the performance numbers
above are comparing apples to oranges.
I fail to see what I'm missing from meson that would have an effect on the
times I reported. There are some files that are installed by autoconf that I
didn't bother to install with meson (because I don't expect this to land). Since
I didn't time installs, I don't see how it isn't an apples to apples comparison.
deal breaker.
I understand that libdrm is a pessimal case for recursive-make since mostThat's correct. If is so concerned - they should slim down the configure.ac ;-)
sub folders contain < 5 C files, However, even if you were to flatten the make
files meson+ninja would still be faster when you consider that meson
configures and builds faster than autotools configures.
There are real limits as to what you can do there.
Yes that was more than clear. Yet it won't fly, I'm afraid.If you/others are unhappy with the build times of libdrm - poke me on
IRC. I will give you some easy tips on how to improve those.
You have some good python knowledge - I would kindly urge you to
improve/rewrite the slow and/or hacky python scripts we have in mesa.
This is a topic that was mentioned multiple times, and a part where
everyone will be glad to see some progress.
Thanks
Emil
The real goal here is to do mesa (in case I didn't make that clear either), and
the advantage for mesa is not just performance, it's that meson supports visual
studio on windows; which means that we could hopefully not just get faster
builds, but also replace both autotools and scons with a single build system.
The VMWare people like their SCons,
How much? I would really rather the VMWare people speak on behalf of VMWare. Meson is the single best shot we've ever had for replacing both with one build system. I'm sure the VMware people would like to have a build system that gets maintained by the community as a whole.
Sure, I'd like to see one build system instead of two. Meson supports Windows so that's good. But the big issue is our automated build system. Replacing SCons with Meson could be a big deal in that context. It would at least involve pulling Meson into our toolchain and rewriting a bunch of Python code to grok Meson. I'd have to go off and investigate that to even see if it's a possibility. Maybe next week.
-Brian
and Meson is not a thing on neither BSD(s), Solaris (and derivatives) nor Android :-\
I have trouble bringing myself to care. The BSDs need to stop using 10 year old compilers. It can be made to work on Solaris and BSD if someone bothered to put a little work into it. Besides, given that large chunks of GNOME are switching they're going to have to make it work some day soon anyway.
Android is a bit unfortunate. Mesa is one of the few projects that let's the Android people carry their build system in-tree and I would like to keep that going if it were practical. Dylan and I have talked about this a decent bit and one potential solution is to see if the meson people would accept an Android back-end. Then we would be down to a single build system (wouldn't that be nice).
If there's something "slow" say what/where and we can improve upon
things. You seems to be rewriting $world because someone sold you that
A is the holy grail.
I don't think that's fair. No, Meson is not the holy grail but it is the closest anyone has yet been able to come to a viable autotools replacement.
Speed is only one aspect to this. Unifying the Linux and windows builds is also a significant advantage. Also, autotools is objectively terrible and having a build system that's modifiable be mere humans without the need for hours of pouring over documentation only to find that you did it wrong anyway is a definite plus.
_______________________________________________
mesa-dev mailing list
mesa-dev@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
