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

Vulkan: VkQueryPool being used with VkCommandBuffer of other queueFamilyIndexs #3505

Closed
zehortigoza opened this issue Dec 17, 2024 · 5 comments
Labels
Bug A crash, misbehaviour, or other problem Unresolved Waiting for a fix or implementation

Comments

@zehortigoza
Copy link
Contributor

Description of Bug

VulkanReplay::FetchCountersKHR() creates a VkQueryPool for queueFamilyIndex == 0 but later it is used in VkCommandBuffer of different queue families not respecting Vulkan specification and causing issues in Intel GPUs with support for multiple queues(Lunar Lake and newer).

I can workaround it by using a environment variable(ANV_QUEUE_OVERRIDE=gc=1,g=0,c=0,v=0,b=0) that disables all queues but the main one(that supports VK_QUEUE_GRAPHICS_BIT | VK_QUEUE_COMPUTE_BIT | VK_QUEUE_TRANSFER_BIT) but would be nice to have renderdoc to following specification.

Steps to reproduce

  • renderdoccmd capture ... <application being analyze>
  • qrenderdoc <file captured above>
  • Performance Counter Viewer tab > Capture counters > Vulkan Extended > Sample counters
  • VK Device is lost

Again this is only reproduced in GPUs that supports multiple queues, for Intel on Linux that would be Lunar Lake(Ultra series 2) and Battlemage(Arc B). I can definitely help with testing.

Environment

  • RenderDoc version: v1.x branch from today / commit 4ac6b77
  • Operating System: Linux
  • Graphics API: Vulkan
  • HW: Intel Lunar Lake(Ultra series 2)
@baldurk
Copy link
Owner

baldurk commented Dec 17, 2024

I'll look into this but at this stage it won't be until the new year. The KHR counter queries were originally contributed by @djdeath so possibly he can look into it sooner? Looking at the original PR #1600 this was mentioned as a known issue but not addressed at the time.

Also note you should never use renderdoccmd. This is an undocumented internal tool only and not for users. You should launch your program for capture from the RenderDoc UI rather than doing that as an unnecessary extra step.

@baldurk baldurk added Bug A crash, misbehaviour, or other problem Unresolved Waiting for a fix or implementation labels Dec 17, 2024
@djdeath
Copy link
Contributor

djdeath commented Dec 17, 2024

Running out of time too for this year :(

I can look into it after, shouldn't be hard to avoid emitting the queries in the not supported command buffers.

@baldurk
Copy link
Owner

baldurk commented Jan 6, 2025

@djdeath I'm catching up after the holidays - I'll leave this with you for not but let me know if you're not able to get to it and I will try and resolve the issue.

@baldurk
Copy link
Owner

baldurk commented Jan 27, 2025

That commit should ensure that queries are only fetched for the supported queue.

@zehortigoza
Copy link
Contributor Author

That commit should ensure that queries are only fetched for the supported queue.

that worked, thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A crash, misbehaviour, or other problem Unresolved Waiting for a fix or implementation
Projects
None yet
Development

No branches or pull requests

3 participants