[Mesa-dev] Directly using upstream headers (Was Re: [PATCH] vulkan: Don't install vk_platform.h or vulkan.h.)

[Eric Engestrom]

On Thursday, 2017-01-26 18:54:59 +0000, Emil Velikov wrote:
> On 25 January 2017 at 22:10, Chad Versace <chadversary at chromium.org> wrote:
> > On Tue 24 Jan 2017, Jason Ekstrand wrote:
> >> On Tue, Jan 24, 2017 at 11:25 AM, Emil Velikov <emil.l.velikov at 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