On Fri, Nov 3, 2017 at 6:28 PM, Christian Schmidbauer <ch.schmidba...@gmail.com> wrote: >> 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)?
That's the main difference between debug and debugoptimized. > 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. Yes... we call it "debugoptimized" :) _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev