On Tue 24 Jan 2017, Jason Ekstrand wrote: > On Tue, Jan 24, 2017 at 11:25 AM, Emil Velikov <[email protected]> > wrote: > > On 24 January 2017 at 18:02, Jason Ekstrand <[email protected]> wrote: > > On Tue, Jan 24, 2017 at 9:03 AM, Matt Turner <[email protected]> wrote: > >> > >> On Tue, Jan 24, 2017 at 8:41 AM, Emil Velikov > <[email protected]> > >> wrote: > >> > On 24 January 2017 at 00:54, Matt Turner <[email protected]> wrote: > >> >> These files belong to the vulkan loader. > >> > Fully agreed, patch is > >> > Reviewed-by: Emil Velikov <[email protected]> > >> > >> Thanks! > >> > >> > Related question: > >> > I was wondering about getting this a step further: > >> > - having the loader provide a .pc file > >> > - tracking required version at configure time and dropping our local > >> > copies of the headers/xml. > >> > > >> > Would you be in favour, against, neutral of such an approach ? > >> > >> I'd be in favor of that, but let's see what Jason thinks. > > > > > > I'd rather not. That would make sense if we all lived in the > open-source > > world where everything is upstream all the time. Unfortunately, not all > of > > us have that luxury and we need to be able to work on experimental > branches > > of the spec that may have more extensions than are provided by any > loader > > version we can install. I'd be ok with a check for a particular loader > > version just to force distros to update their loader but I would like to > be > > able to build with arbitrary XML branches without having to install a > branch > > of the loader. > What if I tell you that you wouldn't need to install the loader ;-) > More as we get a .pc patches in. > > > A lot of extensions don't require explicit loader support. I don't want to > have to update my loader (or put it in some folder and point pkg-config at it) > just to hack on them.
Matt's patch gets my Reviewed-by: Chad Versace <[email protected]> And, Mesa should build Vulkan against its own imported headers. Otherwise, the Mesa build would effectively require version lock between it and the installed loader headers; this version lock is made more difficult because the loader headers aren't really versioned. Upstream unintentionally breaks things. When I bisect Mesa with a git-bisect script, I do not also want to hack the script to checkout and re-install the loader during the bisect. Evidence: https://cgit.freedesktop.org/mesa/mesa/commit/?id=c085bfcec9915879e97a33c5235cf21607c72318 A Bigger Problem: You cannot force the distro to upgrade its loader headers. If the loader-provided headers on Android N differ from those on Android O and Android P due to stupid upstream API breakage, and those once again differ from those in Fedora 25 and Fedora 29... Despite that, Mesa must continue to build on all supported platforms. Satisfying that may be hellish if Mesa builds against the system's Vulkan headers instead of its own. _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
