On 25 January 2017 at 22:10, Chad Versace <chadvers...@chromium.org> wrote: > On Tue 24 Jan 2017, Jason Ekstrand wrote: >> On Tue, Jan 24, 2017 at 11:25 AM, Emil Velikov <emil.l.veli...@gmail.com>
>> > 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. > > 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. In generally it's a matter of ensuring people do the better/more robust (?) thing. Sadly that means a bit (albeit somewhat trivial) amount of work on each side. From Vulkan (Mesa in general) developers, POV: - to point to the specific files Distributions: - update regularly Khronos: - ensure that both headers and XML files are updated for development branches... Having the script which generates vulkan.h/other publicly accessible would be also nice ;-) - write tests and wire those to make check (or equivalent) In practise neither one is easy due to the amount if people it needs to be coordinated with. And considering that people are always busy with more important thing... I don't see it happening soon :-( Either way, I hope we don't get to a situation similar to the *GL* headers. Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
