On Thursday, 2017-01-26 18:54:59 +0000, Emil Velikov wrote: > 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 ;-)
It is :) https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0/src/spec/genvk.py ./genvk.py -registry vk.xml vulkan.h > - 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
