[PATCH 1/2] winevulkan: Allow some experimental VK extensions to be translated.

[Henri Verbeet]

On Mon, 10 May 2021 at 19:36, Liam Middlebrook <lmiddlebrook at nvidia.com> wrote:
> On 5/10/21 6:10 AM, Henri Verbeet wrote:
> > On Mon, 10 May 2021 at 12:29, Liam Middlebrook <lmiddlebrook at nvidia.com> wrote:
> >> +# Some experimental extensions are used by shipping applications so their API is extremely unlikely
> >> +# to change in a backwards-incompatible way. Allow translation of those extensions with WineVulkan.
> >> +ALLOWED_X_EXTENSIONS = [
> >> +    "VK_NVX_binary_import",
> >> +    "VK_NVX_image_view_handle",
> >> +]
> >> +
> > I would be inclined to say those applications are abusing the system,
> > and we shouldn't be enabling that. On the other hand, if NVIDIA is
> > generally fine with applications/vendors doing this kind of thing, is
> > there any point in distinguishing between NV and NVX extensions at
> > all? I.e., in that case, we might as well just get rid of the code
> > skipping NVX extensions, because their API is effectively going to be
> > frozen the moment a non-zero number of applications use them.
> >
>
> I wouldn't classify our stance as "generally fine" here. The position
> here certainly isn't a good one for anyone to be in. Production
> applications shouldn't be making use of experimental extensions (as the
> API normally could change with later spec versions). But given that
> applications have started to use these extensions the API for them can't
> change (at least not in a backwards-incompatible way), since we can't
> break those use cases.
>
Would it make sense to make that explicit in the extension spec? E.g.
by adding a note along the lines of "Despite starting out as an
experimental extension, the API has been frozen since revision
<revision>."

> I think given the above, it makes sense to allow WineVulkan to add
> support for these two extensions. We shouldn't encourage applications to
> make use of experimental extensions in production environments in the
> future, but I don't see a strong benefit to holding that stance for
> these extensions which are de facto API stable.
>
I think there are (at least) two parts to this:

  - On the winevulkan side, sure, but then that same reasoning works
if a sufficient important (for some definition of "important")
application starts using e.g. VK_NVX_multiview_per_view_attributes. At
the same time, if no application we particularly care about uses a
specific NVX extension, there's no particular harm in exposing it, and
we might as well save ourselves the trouble of skipping NVX
extensions.
  - On the broader Vulkan ecosystem side, the current approach has the
effect that some applications/vendors can force NVIDIA to make an
experimental extension de facto stable, while some other
applications/vendors can't. Ultimately that seems more harmful than
simply asking the offending people to please fix their application,
and breaking it if they don't.