KhronosGroup / KhronosGroup/Vulkan-Docs

Unclear if a device should advertise support for rendering to a desktop rendered by another device

Open
#37 10 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Specification System Integration
Dominant language
JavaScript
Stars
3.3k
Forks
549
Avg merge
5d 5h
Merged PRs (30d)
2

Description

On some systems there can be several cards available.

Examples are:
. Crossfire/SLI configurations: one of the cards is connected to the display and renders the desktop
. Laptops: iGPU renders the desktop and is connected to the display OR dGPU renders the desktop and iGPU is used to communicate the rendered content to the display.

With GL, rendering to another device than the one used to render the desktop implies some hidden operations (allocation of buffer both devices can understand in some shared memory, potentially some hidden copies, etc).

Current WSI spec of vkGetPhysicalDeviceSurfaceSupportKHR doesn't specify if the cards not used for the rendering of the desktop should advertise support or not.

Both not advertising support and supporting but with some hidden operations seem allowed by the current spec. Could it be clarified ?

I believe it is important to specify it.

  1. If only the device used for desktop rendering is allowed to advertise support, then apps would have to iterate over the devices to find the one supporting the surface (And I guess with some future extension it will be possible to render with other devices and share buffers such that you could present with the device supporting rendering to the surface).

  2. If all devices are allowed to advertise support, it seems rather difficult for the apps to pick one, and it may result in suboptimal choice.

I guess the behaviour is linked to the -likely being written- extension to share data accross devices, and my guess is that 1) implies that the work done to render to a different gpu than the desktop will have to be done by the app, whereas 2) will hide that in the driver.
I prefer 1) personally.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the current WSI specification for vkGetPhysicalDeviceSurfaceSupportKHR and review how it describes devices that render a desktop through another device. Compare the two behaviors described in the issue, then clarify which devices may advertise support and what the expected application or driver responsibilities are.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.