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

layers: Set up QUEUE_STATE and PHYSICAL_DEVICE_STATE at create time #3370

Merged

Conversation

jeremyg-lunarg
Copy link
Contributor

No description provided.

@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build queued with queue ID 44650.

@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build # 5004 running.

@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build # 5004 failed.

@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build queued with queue ID 1429.

@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build # 5205 running.

@jeremyg-lunarg
Copy link
Contributor Author

@mikes-lunarg , you're really good at pointing out dispatch problems... Do you see anything wrong with this approach?

@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build # 5205 failed.

@jeremyg-lunarg
Copy link
Contributor Author

@mikes-lunarg , you're really good at pointing out dispatch problems... Do you see anything wrong with this approach?

Ugh, of course there's something wrong. I need to call vkGetDeviceQueue2*() if it is a protected queue.

@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build queued with queue ID 1558.

@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build # 5217 running.

@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build # 5217 failed.

Copy link
Contributor

@ncesario-lunarg ncesario-lunarg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@jeremyg-lunarg
Copy link
Contributor Author

still gotta figure out what is wrong on internal CI tho

Set up these state objects immediately rather than waiting for
the application to enumerate them. This ensures that the contents
of physical_device_map won't change during the lifetime of the
instance.
@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build queued with queue ID 2939.

@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build # 5239 running.

Set up the state objects immediately rather than waiting
for calls to vkGetDeviceQueue(). This ensures that the contents
of queueMap won't change during the lifetime of the device.
@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build # 5239 failed.

@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build queued with queue ID 2976.

@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build # 5241 running.

@ci-tester-lunarg
Copy link
Collaborator

CI Vulkan-ValidationLayers build # 5241 passed.

@jeremyg-lunarg jeremyg-lunarg merged commit a15e238 into KhronosGroup:master Oct 18, 2021
@jeremyg-lunarg jeremyg-lunarg deleted the jeremyg-physdev-init branch October 19, 2021 14:30
gnoliyil added a commit to gnoliyil/Vulkan-ValidationLayers that referenced this pull request Jan 3, 2022
A previous change (KhronosGroup#3370)
makes state tracker only set up the queue state objects on
vkCreateDevice() instead of on each vkGetDeviceQueue() call.
However, this breaks some devices (e.g. goldfish-vulkan virtual
ICD which is used for Android and Fuchsia emulator) where it
could possibly return different queue handles on vkGetDeviceQueue().

In order to handle this case, state tracker should still try to
update the queue map on each vkGetDeviceQueue() call.

TEST: vkreadback (on Fuchsia emulator)
Change-Id: Ib7a3f3b9808b5a7067bbcf0d1d97f7d7869dfd84
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants