Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support the extension VK_QCOM_multiview_per_view_viewports #3269

Open
mazvalente opened this issue Mar 5, 2024 · 5 comments
Open

Support the extension VK_QCOM_multiview_per_view_viewports #3269

mazvalente opened this issue Mar 5, 2024 · 5 comments
Labels
Feature An improvement or feature Unresolved Waiting for a fix or implementation

Comments

@mazvalente
Copy link

mazvalente commented Mar 5, 2024

Description

I would like RenderDoc to add support for the VK_QCOM_multiview_per_view_viewports extension so that captures without shader specific multiviewport implementations can correctly display multiple viewports. I would like the submitted viewports and scissors to be visible in the API Inspector while providing the different views generated through the Subresource slice/face dropdown selector. Additionally, I would like the viewport/scissors overlay to reflect this change and cover the correct scissors region based on the view it is overlaying.

I believe that the change should mainly involve implementing the extension and altering the overlay replay functionality to provide it more information on which view it is overlaying which it can use to alter the shown viewport/scissors region. However, it seems like I am missing some information or details on how this should be best implemented.

Environment

RenderDoc version: This was initially worked on in version 1.29 but remains unchanged in current version 1.31.
OS: Android, tested on the Quest 2 and 3 VR headsets
Graphics API: Vulkan

@baldurk
Copy link
Owner

baldurk commented Mar 5, 2024

You seem to have entangled different issues here. First there is the question of supporting a new extension, but you're saying that if the extension isn't supported then there is a bug in the display of multiple viewports or scissors?

Please open a separate issue for a bug like that and leave this issue only for requesting support of a new extension.

@baldurk baldurk added the Unresolved Waiting for a fix or implementation label Mar 5, 2024
@mazvalente
Copy link
Author

Ok, I've removed the bug fix from the request and changed it to just refer to the extension + overlay support change.

@baldurk baldurk added the Feature An improvement or feature label Mar 5, 2024
@baldurk
Copy link
Owner

baldurk commented Mar 5, 2024

If there's a bug to report then please file an issue for it and provide steps to reproduce the problem. That is higher priority than a feature request for a new extension, and a bug in the existing code will not get fixed by implementing a new extension.

@mazvalente
Copy link
Author

I will, but I'm first trying to confirm with the person who implemented the extension in the engine to make sure that this is a genuine RenderDoc bug and not something that occurred because of the engine's behavior if the extension is not enabled. I have 2 implementations I'm working with and on Unreal Engine I'm not seeing the bug, only on Unity, so it may be a failure on that side to handle the extension not being supported.

What I am getting regardless is only 1 viewport/scissor being submitted, hence the feature request.

@mazvalente
Copy link
Author

I've received confirmation that the bug is not a RenderDoc bug, instead being a Unity issue where a part of the pipeline is unable to determine whether the extension was enabled or not and is defaulting to enabled in my sample, causing the frame submissions to be incorrect if the extension is disabled.

The only request is feature enablement to support viewing the correct viewport/scissor regions for each view and an overlay update to likewise display the correct region for each view.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature An improvement or feature Unresolved Waiting for a fix or implementation
Projects
None yet
Development

No branches or pull requests

2 participants