[Mesa-dev] [PATCH] docs: Add Vulkan to features.txt

[Jason Ekstrand]

On Tue, Aug 1, 2017 at 4:29 AM, Bas Nieuwenhuizen <bas at basnieuwenhuizen.nl>
wrote:

> On Tue, Aug 1, 2017 at 1:27 AM, Jordan Justen <jordan.l.justen at intel.com>
> wrote:
> > On 2017-07-31 16:08:51, Bas Nieuwenhuizen wrote:
> >> On Tue, Aug 1, 2017 at 12:32 AM, Jordan Justen
> >> > +Vulkan 1.0 -- all DONE: anv
> >>
> >> So while we don't have conformance, we have at several times had local
> >> conformance suite runs pass all tests, so I think we can write up radv
> >> as all done here too?
> >
> > Ok, I can add radv here if you recommend it.
> >
> >> > +
> >> > +Khronos and EXT extensions that are not part of any Vulkan version:
> >> > +  VK_EXT_acquire_xlib_display                           not started
> >> > +  VK_EXT_blend_operation_advanced                       not started
> >> > +  VK_EXT_debug_marker                                   not started
> >>
> >> Do we even want to implement this as driver, or let this be for the
> layers?
> >
> > I just used grep to find the extensions. If the consensus is to drop
> > this, I can do that.
>
> So the question here is do we want to have a generic list of supported
> features or more like a TODO list. if its the former, adding it would
> be ok, if its the latter I'd think adding this (and the win32 exts are
> for mesa also unlikely) extension to the list would be kind of
> misleading.
>

That's a very good question.  Here's what I see in GL and I think it's
probably reasonable:

 1) There is a section for each OpenGL version 3.0 and above with what
extensions are required by that version.  We only have Vulkan 1.0 today but
I'm sure new versions are coming.

 2) Theree is a section for all KHR, ARB, and OES extensions not yet tied
to any particular OpenGL version

 3) The only EXTs listed are those which got promoted directly to core
without going through ARB first.  There are not many of these but they
happen.  Mesa supports piles of EXTs which are not in features.txt.

I think we should follow a similar pattern.  I really don't want this to
come back and bite us.  Lists of features have this nasty tendency to turn
into ToDo lists.


> >
> >> > +  VK_KHX_multiview                                      DONE (anv)
>

I'd be a fan of not listing KHX extensions in features.txt.  They're
experimental and guaranteed just to go away at some point.


> >> I started this one for radv too, not sure if we put those in if one
> >> driver already has them though.
> >
> > Based on GL, I don't think we have a way to indicate that it is
> > started for another driver after one has completed it. Do you have a
> > recommendation?
>
> If GL doesn't do it, lets leave it alone for vulkan.
>
> >
> > Side note: Looking at the header of the file, it looks like I should
> > use 'in progress' rather than 'started'.
> >
> >> btw, no vendor extensions?
> >
> > Looking at the 'Khronos, ARB, and OES extensions that are not part of
> > any OpenGL or OpenGL ES version' section, it doesn't seem to include
> > vendor extensions. I did see a few 'NV' extensions in other sections
> > of the file, but I think in those cases they were rolled into the core
> > versions.
> >
> > Should we add another section for extensions that at least 1 driver
> > has implemented or started to implement?
>
> I think that would be nice as some of the AMD/NV exts seem to be
> implementable cross-vendor. Not a blocker though for adding this.
> >
> > -Jordan
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170801/99d9c63e/attachment.html>