xref: /third_party/vk-gl-cts/external/vulkan-docs/src/proposals/Roadmap.adoc

// Copyright 2021-2024 The Khronos Group Inc.
//
// SPDX-License-Identifier: CC-BY-4.0

# Vulkan Roadmap
:toc: left
:refpage: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/
:sectnums:

This document proposes the development of a shared public roadmap for features across mid-to-high-end devices in smartphone, tablet, laptop, console, and desktop markets.


## Problem Statement

While each hardware vendor determines their own roadmap, input from platform owners and software vendors does influence those roadmaps, and having some of this discussion within Khronos enables vendors to ensure applications can target a standard set of features across the ecosystem.

In the OpenGL/ES era, standardising support for features was done by adding them to new versions of the APIs, but in Vulkan core versions are only really adding software and infrastructure improvements.
As such there is no current formalization of a shared roadmap; any agreement among the working group has been informal and ad hoc, buried in meeting minutes.
If any vendor diverges in even one feature from the rest of the industry, then that feature cannot be relied upon by developers and the market is fragmented - arguably a failure at standardisation.
Feature fragmentation is a particular problem for mid-to-high-end devices across smartphone, tablet, laptop, console, and desktop markets; developers often target a large number of these devices with demanding applications. Often these applications wish to make use of a range of newer features, but a lack of guarantees about feature support across the target devices makes it hard to find a reliable set.


## Solution Space

In order to reduce that fragmentation, the options available are roughly as follows:

 - Do nothing, and rely on external pressure to drive the feature set
 - Create a feature roadmap with defined milestones that have support guarantees

Up until now we had primarily relied on external pressure to drive feature support, but it is apparent that this is not reliable.
A number of features still do not enjoy wide support, and it is difficult to figure out what the market penetration for a given feature is.
Different vendors prioritise features differently based on the set of developers they talk to, and while over time the base feature set is growing, it has a very long tail.

Facilitating a roadmap definition would allow the Vulkan members a way to share collective feedback so that everyone has access to the same information, giving a clearer picture of how to prioritise features.
Ideally by planning well in advance of a release, it will give vendors time to adjust software and hardware roadmaps to align with the wider industry and ultimately reduce fragmentation in future implementations across the identified markets.

This document proposes that the creation and ongoing maintenance of a feature roadmap for the Vulkan working group.
Possible ways of defining a roadmap include:

  . Having an internal shared roadmap
  . Having a public shared roadmap

Having a shared roadmap documented internally to Vulkan will allow vendors to collaborate and agree on what the shared roadmap is going to look like, which solves most of the problems.
If the shared roadmap is published, it adds a lot more scrutiny on hardware vendors - everyone will be able to see if a particular vendor has chosen to ship new hardware that does not meet the roadmap requirements.
A public roadmap should also lead to a wider range of feedback and discussion; which ultimately should result in a better end product.
Due to the accountability and potential for more open feedback, this document proposes designing a public roadmap for the Vulkan WG.

Ultimately the roadmap will become a series of milestones with support guarantees tied to a particular point in time - documenting these can be done in a number of ways:

  . Making them part of a core version
  . Making them into extensions
  . Documenting them separately

Requiring features in core versions is how things worked for OpenGL and OpenGL ES, and it had enough flaws that this explicitly stopped in Vulkan, with much more caution applied before requiring a feature.
By not doing this in Vulkan, it has allowed the core version to raise the infrastructure baseline without cutting out old hardware, allowing broader support for new versions.
There is an additional issue that becomes more apparent with a single core API instead of two as well; which market should define the features in a new core version?
Vulkan serves the same markets as OpenGL/ES did, which includes even embedded devices - a market that is unlikely to care too much about the latest hardware features for high end graphics.
This either severely limits the possible impact of requiring features in a core version, or means that certain markets will only be able to support older versions, and are forced to follow the same features.

As for extensions, the roadmap milestones may be retroactively descriptive at the time they are released, and an implementation already supporting the required set of functionality may not be able to get driver updates allowing a milestone extension to be exposed.
As such, putting the roadmap milestone in the API as an extension would mean some implementations would be excluded from advertising support for the milestone despite supporting all the functionality.

Using separate documentation of the milestones allows markets to evolve requirements separately from the API version, allows multiple markets to coexist while maintaining awareness of how they are each evolving within Khronos, and ensures applications do not rely on extensions as a potentially unreliable mechanism.
The API specification will describe the milestone, but the detection of a milestone on a given device can be deferred to external tooling.

This proposal details the documentation of the roadmap milestones as separate documentation, supported by external tooling. This proposal does not go into detail about the external tooling, which is being defined separately, but is being designed with the requirements noted in this proposal.


## Proposal

Similar to how extensions are defined, this proposal suggests adding a definition of roadmap milestones to the Vulkan specification, though these will not be a part of the API itself.
Each milestone will be defined as a set of required features and extensions, increased limits, and required versions.


### Target Markets

The current roadmap plans account for Vulkan’s most demanding markets - mid-to-high-end across smartphone, tablet, laptop, console, and desktop, but other markets continue to remain important to Vulkan. Embedded systems, wearables, and other area-critical markets currently track the core Vulkan baseline, and future feature planning will continue to account for this. Vulkan SC and the Vulkan portability effort address unique market segments with their own needs that aren’t captured by the current roadmap effort; these initiatives will continue to evolve independently where necessary. If any notable markets emerge with unique needs across a large number of vendors, we could facilitate additional roadmaps.


### Defining the roadmap

The roadmap should be initially defined as a set of problems that the Vulkan working group determines should be solved as a priority based on industry input, with rounds of feedback both internally and publicly.
Periodically, the working group should reevaluate the priorities of these problems, and plan to work towards addressing the highest priority items.
One of the products of these efforts is likely to be new API features, which will become candidates for including in roadmap milestones.


### Milestone release cadence

The cadence of releasing new roadmap milestones is likely to be somewhat coincident with hardware vendor architecture refreshes, which often take somewhere between 3-4 years.
Given the current cadence of Vulkan versions every 2 years, it is likely that roadmap milestones could be aligned to a 4 year cadence.
This is not a given, but can be considered reasonable upper bound.

Releasing roadmap milestones once a year is likely to just confuse the market; one year is unlikely to be enough for developers to settle on a single roadmap milestone, or for implementors to align their internal roadmaps enough for significant pieces of functionality.
A 2 year cadence, being exactly coincident with core version releases, would likely be the lower bound, as it works relatively well for core versions.

The actual criteria used to decide on releasing a roadmap milestone will be whether a roadmap milestone adds notable value to developers, and a reasonable cadence will need to be determined as the working group gains experience with the roadmap.
However, the working group will aim to have a new milestone within four years of a prior milestone as a default position, as long as Vulkan remains relevant.


### Criteria for including a feature in a milestone

Features should only be included in a roadmap milestone if the feature is proven to address identified problems in a reliable manner.
Any feature which remains unproven across all target markets must not be included in a roadmap milestone.

Milestones should have a year associated with them and a clear indication of support from vendors offering hardware to the target markets that can be publicly advertised.
If a feature does not have commitment for support by the end of that year (or shortly thereafter) from all vendors supplying mid-to-high-end devices in the target markets, it must not be included in the roadmap.


### Milestone Documentation

Milestones will be documented in an appendix to the Vulkan specification, as well as features and limits being documented in the specification text body.
In addition, external tooling is being developed to define and manage "profiles" in a standard format for ease of use, and milestones should additionally be defined as a profile in this same manner.


### Initial milestone

An initial milestone should be developed and published to determine the current state of implementation support.
This will not allow for time to modify roadmaps significantly, but it should give time to align some software on top of existing hardware support.