> On Thu, Nov 2, 2017 at 11:45 AM, Andres Rodriguez <andre...@gmail.com> wrote: >> >> >> On 2017-11-02 01:52 PM, Eric Engestrom wrote: >>> >>> On Thursday, 2017-11-02 17:39:53 +0000, Eric Engestrom wrote: >>>> >>>> On Thursday, 2017-11-02 09:46:05 -0700, Chad Versace wrote: >>>>> >>>>> On Wed 01 Nov 2017, Dylan Baker wrote: >>>>>> >>>>>> Quoting Ilia Mirkin (2017-11-01 16:05:17) >>>>>>> >>>>>>> On Wed, Nov 1, 2017 at 7:03 PM, Dylan Baker <dy...@pnwbakers.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Quoting Ilia Mirkin (2017-11-01 15:52:56) >>>>>>>>> >>>>>>>>> On Wed, Nov 1, 2017 at 6:49 PM, Chad Versace >>>>>>>>> <chadvers...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>> On Wed 01 Nov 2017, Dylan Baker wrote: >>>>>>>>>>> >>>>>>>>>>> Quoting Chad Versace (2017-11-01 14:43:28) >>>>>>>>>>>> >>>>>>>>>>>> Wow. 10 seconds from a clean checkout to an installed Vulkan >>>>>>>>>>>> driver. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Glad that it's working out for you guys! >>>>>>>>>>> >>>>>>>>>>> Can I convince you to wire the anvil and i965 android/arc++ bits? >>>>>>>>>>> ;) >>>>>>>>>>> >>>>>>>>>>> JFYI, the meson build will (I consider it a bug if it doesn't) >>>>>>>>>>> turn off all >>>>>>>>>>> glapi, egl, and glx if there are no dri or gallium drivers built >>>>>>>>>>> unless you >>>>>>>>>>> force them on. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks for turning that stuff off. Last time I tried to build just >>>>>>>>>> Vulkan without GL (maybe 1.5 years ago), Autotools didn't allow it. >>>>>>>>>> It >>>>>>>>>> insisted that i965 was a build dependency for anvil. >>>>>>>>>> >>>>>>>>>>> It also avoids building the glsl compiler unless there's a driver >>>>>>>>>>> that uses it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I expected the buildtime to be much longer because I expected it to >>>>>>>>>> build the GLSL compiler too. I was surprised and happy to discover >>>>>>>>>> that >>>>>>>>>> it builds only the SPIR-V compiler. >>>>>>>>>> >>>>>>>>>>> And it defaults to debug, which might be surprising, but people >>>>>>>>>>> around here thought that default debug is a feature. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Huh... For infrastructure projects like Mesa (as opposed to test >>>>>>>>>> projects like Piglit), I expect the default build to be the release >>>>>>>>>> build. But I can understand why others would want default=debug. >>>>>>>>> >>>>>>>>> >>>>>>>>> autotools defaults to debug disabled. I think that's how almost >>>>>>>>> every >>>>>>>>> project does it... debug enabled is definitely a surprise. >>>>>>>>> >>>>>>>>> -ilia >>>>>>>> >>>>>>>> >>>>>>>> Well, for distros they likely want to set the buildtype to plain >>>>>>>> (meson adds no >>>>>>>> compiler flags except ones the project defines), and then add their >>>>>>>> default >>>>>>>> flags via CFLAGS and CXXFLAGS. That is certainly *not* what anyone >>>>>>>> except a >>>>>>>> distro (or some kind of build infrastructure like jenkins or gentoo) >>>>>>>> would want. >>>>>>>> Xorg's default is debugoptimzed, for reference. >>>>>>> >>>>>>> >>>>>>> --enable-debug enables -DDEBUG in mesa. Are you saying that this is >>>>>>> the default? Or are you just saying that you're not adding extra >>>>>>> -O100073 options? >>>>>> >>>>>> >>>>>> The meson build keys -DDEBUG on the builtype, debug or debugoptimized >>>>>> you get >>>>>> -DDEBUG, anything else, you don't. The way mesa is setup if you don't >>>>>> have >>>>>> -DNDEBUG you have to have -DDEBUG or asserts happen for member of >>>>>> structures >>>>>> that don't exist. >>>>>> >>>>>> I'm not dead set on debug as the default buildtype, it's what we have >>>>>> ATM >>>>>> though. I asked around here and the feeling was that builtype debug by >>>>>> default >>>>>> was a feature. If the larger community disagrees we can change it. >>>>> >>>>> >>>>> When making this decision, I think we should also consider the needs of >>>>> non-developers who build and install Mesa from source to get the latest >>>>> version or bugfix. I strongly suspect those people want >>>>> buildtype=debugoptimized or buildtype=release. >>>>> >>>>> I think it's important for Mesa to follow the established convention of >>>>> most other Linux projects: if a user downloads the source, builds, and >>>>> installs, then the user gets a working installation suitable for normal >>>>> usage. Today, Meson doesn't give that because it builds Mesa with -O0. >>>>> >>>>> Some context... I install a lot of packages from source on my work >>>>> machine because I often want or need newer versions of some packages >>>>> than what's available through the package manager. >>>> >>>> >>>> How do you ensure it integrates correctly with your system [1], other >>>> than by using the package manager's package and updating the version >>>> number locally? >>>> >>>> [1] by "integrate" I mean things like installing things in the right >>>> locations, removing stale files from old packages, providing new >>>> dependencies for other packages, etc. >>>> >>>> I also install newer version of stuff on various machines, but if I had >>>> to configure each project manually to integrate with my system, then >>>> I would just give up. That burden does not scale :P >>>> >>>> The only way I can make this work is by grabbing the existing package, >>>> bumping the version and recompiling it. Part of the configuration set in >>>> the package is the various optimisation flags, be that through >>>> buildtype=release or buildtype=plain + manual cflags. >>>> >>>> (Note that for Meson, Arch provides a wrapper [2] that sets all the >>>> options to the right values for ease of use.) >>>> [2] >>>> https://git.archlinux.org/svntogit/packages.git/tree/meson/trunk/arch-meson >>>> >>> >>> I think I wasn't clear, but my point was that IMHO the only time someone >>> would build something without going through a package is when they're >>> dev'ing it, in which case buildtype=debug is what they want. >>> >>> It's not too hard to ask all the devs to manually set it every time >>> though, >>> especially since we're all used to having to do it with autotools. >> >> >> I think this is one of the better reasons to go with an optimized build type >> by default. >> >> Additionally, it is very easy for a developer to realize that a build is >> missing debug symbols (you'll get the feedback from your debugger >> immediately). However, a user might never notice that their build is not >> optimized. This can lead to a bad experience that could've easily been >> avoided, and possibly some noise in bug reports. >> >> As Eric mentioned, the cost of setting the build type from a dev point of >> view is minimal and probably worth offsetting the issues mentioned above. > > This makes sense to me. > > In the autotools system we have today, we have --enable-debug, which > adds -g and -O0 if some -g* and -O* are not already in CFLAGS. It also > adds -DDEBUG which turns on lots of debugging code that has extra > runtime cost, like nir_validate. Without --enable-debug, we pass > -DNDEBUG to disable assertions, and otherwise use autotools' default > CFLAGS (-g -O2) or whatever the user specified. > > Meson's debug build should correspond to --enable-debug. > debugoptimized vs release is a little less obvious. Perhaps > debugoptimized should default to -g -O2 but leave assertions enabled, > and release should default to -g -O2 -DNDEBUG? > > Under that system, I agree that the default build type should be > debugoptimized.
Does this mean that it is not easily possible to keep asserations in general but remove heavy extra runtime cost (like nir_validate)? FWIW, it would be great if there would be a "debugoptimized" which tries to keep the overhead minimal and still allow debugging in a sensible, but not complete, way. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev