KhronosGroup / KhronosGroup/Vulkan-Docs

Consider removing odd cases that do not exist in reality

Open
#1,234 1 comment 10 reactions 0 assignees View on GitHub
System Integration
Dominant language
JavaScript
Stars
3.3k
Forks
549
Avg merge
5d 5h
Merged PRs (30d)
2

Description

There are some odd cases allowed in the specification, that really do not happen in reality, and serve only as a red-herring for premature-compatibility minded developers.

Few cases I have identified:

- remove the possibility of a separate-only present queue family
- **rationale**: most of the present engines are sort of a separate\foreign queue, but most of the implementations seem to think it is too extremist and merge the present to the graphics queue family. So while this is considered to be too extremeist to make explicit in practice, I suggest to require any future implementation to do the same.
- remove the possibility of `VkSurfaceCapabilitiesKHR::supportedTransforms` being only `VK_SURFACE_TRANSFORM_INHERIT_BIT_KHR`
- **rationale**: Per hw database does not seem to occur. It is not reasonable to force applications to consider the possibility they have to go to platform API to handle this. Instead I suggest to work with any future presentation engine to make it so that the supported transformation is always available to be queried by the driver and so the driver can inform the app of supported transforms.
- add mandatory swapchain format usages and features that are supported by everyone anyway
- **rationale**: these usages (e.g. `TRANSFER`) seem to be supported by everyone. Given `GRAPHICS` queue family the implementation should always be able to perform copy and blit anyway, so those feature flags should be mandatory.
- #574
- **rationale**: still feels bit like an arbitrary restriction, which are a thing Vulkan should not have. It should be investigated if the original IHV still needs it or if it was always only a theoretical problem. There's probably even a clean solution here: relax this in an extension and promote it in next minor version.
- Remove the possibility the instance has lower version than a physical device
- **rationale**: At least on desktop the driver package installs both. I can't think of a reason why it would be possible to update the ICD, while not being able to update the Loader. At least no reason that is not some artifical and arbitrary platform restriction.
- ?

Contributor guide

Open the contributing guide

Research direction

Review each proposed Vulkan specification change in the issue, including the separate present queue, supported transforms, swapchain usages, instance and physical-device versions, and linked issue #574. Check the cited implementation and hardware-database rationale before narrowing this into a specific proposal. Done means reaching a documented decision for each case or splitting the work into actionable issues.

Written by the indexing model from the issue text.

Assessment

Domain
api, documentation
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.